Sam asked me to put this private discussion on the list:
- Some of the examples are awfull. Exspecially Stars is horrible. I
willrewrite it to get into SDL programming. I will write a rotating zoomer,
too, just to get into it. I guess you can at least double performance
bymaking the transform code inline, then the compiler might be able to
calculate the 3 sin and cos only once per frame and not per point. I
havedone much more points in much less time on an A500, 8 Mhz 68000. Demos
should be fast.I agree. You are more than welcome to improve the demos.
- I don’t like this DEFUN stuff, but I guess there’s no way around it.
Can’t you make a library without it? What is it good for? It makes the
headers less readable. I like things straightUnfortunately there is no way around it (to my knowledge)
The problem is:
The application needs pointers to functions
The library needs actual function definitions
BeOS needs some magic “export” declarations.The only way to do this transparently is to wrap the function definition.
- Is the keyboard code subject to change? It does not map any european
special characters (???) and it should contain some shift/alt key
handling, since european keyboards map the shifted number keys in an
unpredictable way (on my keyboard I get !"?$%&/() for shift 1-9).
Perhapssome translate routine can convert the qualified key code to ansi. I
canshow you my Keyboard codes if you are interested
I would love to internationalize the keyboard code.
I don’t have any experience doing so, however. Ideally, the scancode
handling
would be the same, but SDL_SymToASCII would be replaced with
SDL_SymToUnicode
and dynamic keyboard map loading.
oh, I havn’t notices SDL_SymToASCII. This solves most of my problems. Ok.
- It is very sad that SDL can not change the bit-depth of the XWindows
display. Automatically converting is good, but beeing able to determine
theresolution is the most important thing for a game API.
Yes, this is sad. Console GGI doesn’t have this problem, but has
others…
- testtimer should containt printf(“please wait about 10 seconds.\n”);
Good call – I’ll fix this.
- SDL_Rect could use int, not u16. On Pentium, u16 operations are 4
timesslower then int.
I didn’t realize this. I thought since they were smaller then more
efficient
use of the registers could be made.
“add eax,ebx” is an 1 cycle, pairable instruction on Pentium. "add ax,bx"
needs a prefix costing one extra cycle and is not pairable. additional
cycles come when the compiler has to convert from short to int, I suppose
you use ints as loop counter.
It is a good idea to keep all variables int, make some byte and avoid
shorts if memory is no issue. For medium-sized arrays it might pay to use
shorts and stuff more array elements into to cache.
You can easily speed up Blit1to2 by storing the palette in 32 bit:
old code for one pixel:
*dstp=((Uint16 *)palmap)[*src];
new code for 2 pixels:
*dstp= ((Uint32 *)palmap)[src[0]] + ((Uint32 *)palmap)[src[1]]<<16;
if the compiler does a good job, the 2 pixel loop usually does 2 pixels
faster then the 1 pixel loop does one pixel. Is Blit1to2() the routine
called when you start an 8 bit application on a 16 bit XWindows screen?
When manipulating dirty
rectangle lists for windows systems, {x1,y1,x2,y2}
is much easier to use then {x,y,width,heigt}.Why is that?
There is no particular reason for this, it is just that I found out that I
saves 1/3rd of additions/subtraction. Just imagine a check point in
rectangle and rectangle in rectangle routine, or finding the outer bound of
multiple rectangles using min and max.I don’t want to start holy wars on
rectangle structure.
Your blit routines take two rect’s as input
parameters. I suppose they woun’t stretch the image, so how do you
handlethe redundant size information?
I just verify it. I take a modifiable rect as an input parameter because
it needs to be updated (clipped) and then, along with any dirty rect
accruing,
passed to the update routine. This eliminates redundant clipping in the
copy
and update step.
this is not what i asked.
I suppose I could take a source pair of coordinates and a destination
rect.
Using (w,h) is really nice because then the blit routine becomes:while ( h-- ) {
memcopy(dst, src, w);
++src;
++dst;
}Also, the update routines in some window systems take x,y w,h as
parameters.
You also avoid the “Is x2,y2 part of the copy or not” question.
- Keyboard code could store all information in a 32 bit value. 17 bit
key,15 bit qualifiers. Qualifiers include shift, alt, etc. make/break flag,
“this is a repeat key” flag, numpad flag and perhaps mouse button
statusflags. The highest bit of the key value switches from standard keys
(a,1,ENTER,ESCAPE) to special keys (Cursor, Function, Shifts, Mouse).
Standard keys should be encoded in ANSI, but since 16 bits are reserved
onecould easily switch to UNICODE for future versions. 15 Bit for
qualifiersand 16 bit for special keys leave much room for fancy stuff.
I dunno. Right now, the keys are encoded as 8-bit scancode and 8-bit
modifiers
Translation is done only if needed, to ASCII.Of course, I only have access to a US keyboard.
I didn’t noticed SDL_SymToAscii.
I still havn’t done any coding in SDL yet, I am very busy right now
withour game. I think getting used to it would be the next step for me.
Since Iam looking for a C++ API, and I am looking for a slightly higher level
ofabstraction, I am not totally happy with SDL. Perhaps I change my
libraryso that it easily wraps SDL, then our current game would work with SDL.
Youtold me that there are already C++ wrappers?
That would work very well, I think.
Check out the screenlib example library. That’s a C++ wrapper around
SDL.Do you mind if I CC this to the SDL list?
Done. I CC’ed this reply.
Dierk Ohlerich
@Dierk_Ohlerich