I am back ;-) (xMame 1.06 release)

@MagicSN

You are absolutly right (in theory), but in reality, and in general it must take many time, to polish, fix bugs, optimaze all of this.

In theory SDL can be just like native fucntions by speed. In reality - at moment SDL still have some bugs, some areas of it still unpolished (i think blitter can be faster?) and so on.

I do not know SDL very much (never works with it). It's just includes/functions without any addictions to binary ? (like special startup-sdl code, or somethink like that ?)

@kas1e

Well, if you use the Direct Video RAM function (screen locking) there is really *no* difference between SDL and non-SDL code. Only difference is how the screen is opened...
You could even call the same rendering functions (providing to one the video RAM lock acquired by CyberGfx or P96 API, to the other the lock to the SDL Surface.

The point is there are several kinds of SDL Surfaces...

- YUV Surfaces -> Overlay Support, Direct Video Rendering
- RGB Surfaces directly sitting in Video RAM -> You can directly render into it
- Highlevel Surfaces -> Using SDL's own ASM optimized Refresh functions (still slower than directly hitting Video RAM of course)

Some "lazy" SDL programmers do not support the upper two things (and early SDL-versions do not support them either).

But I cannot see how the same memory copy function is slower if the screen was opened through SDL than if it was opened through OpenScreenTags. It makes no sense.

Steffen

@RacerX

Quote:

My mistake. I forgot to set the stacksize in V.14 to 2000000, which is why V.12 worked and V.14 didn't. Never mind!

Of course mouse support for shooting games would STILL be nice!
(or did I overlook something else?)

Short info update: Optimization still ongoing.

Also starting to update my 0.132 based current Mame source soon to 0.133.

Steffen

@MagicSN

@MagicSN

Hi stef send me an email