You could have put some effort into this thread, this is pathetic. 

woshh: headshot :P 

wow. seriously, Megaman suggestion a decent topic, and already Speedy is a dickbag and ruins it. 

sex thread was better... :| 

What does func think of SDL ? My opinion is, it has overhead compared to OpenGL, and bugs on platforms other than Linux, but it's not too bad. I'm a pretty shit C programmer though.

Trinca - don't enough people tell you you're an **** and should shut up a bit more ? 

Only ever use ressource pools for really expensive objects in languages with garbage collection. The GC is much better optimised to free / remove / reuse instances than your code could ever be.

Negative example:
http://www.ziggyware.com/readarticle.php?forum_id=18&thread_id=13426&article_id=213

I tried a pool some weeks ago on Vector3fs (i was using / creating / releasing lots of em each iteration), and it was way slower than the Java GC.

Positive example: native buffers in java are very slow to create. It's worth saving e.g. one float buffer that you fill with rotation matrices each frame and hand to ogl. 

and if you aren't careful enough (very careful) - instead of the crashes when you use destroyed objects in c++ - you get weird bugs where one object gets used in multiple places... 

In Java, it also depends on the VM you are running on. Some VMs might be better than your code at pooling instances, others might not. I'm not sure whether the Java Spec has rules about how a GC must perform its duties. 

stevenaaus go **** you ****

lol 

yeah, that's probably right. but for a game.. i'd guess the majority of your players will use the Sun VM.

trinca, take your trolling to GA, or something. or maybe the drunk thread ;) 

Still, there may be differences across different platforms even for the Sun VMs for those platforms. You simply cannot make any assumptions if there is no spec. 

school of thought leads nowhere. How do you optimise your code then? 

LH told me that SDL keeps out of the way as much as possible when it comes to drawing stuff. That sounds good, but personally I'll take a non-SDL engine over a SDL one any day. It's clear that there is *some* overhead, even if it's managed intelligently.

I'm still grateful for stuff like PRBoom etc that uses SDL. SDL is snakeoil, but it kinda works. Someone else, it might have been Qudos, said once that SDL was nice to work with.

Bottom line, if I can have an SDL engine or no engine, I'd take SDL...

There are bugs in Linux SDL, too, for example mouse issues where you get "locked" inside a narrow angle, or where you'll suddenly look straight down and start turning uncontrollably. It sometimes goes away when you pause and unpause the game a few times, in PRBoom at least. SDLQuake2 was pretty bad though. 

megaman u�re right ;)

big hug my german friend :)

me quit this thread!!! 

cube and sauerbraten use SDL, they seem pretty solid in terms of mouse input. 

... off-topic, but i'm going to update my howto shortly i hope. Here's a draft.

Suggestions ? GB.. Can't find your HexenII mapping suggestion anymore. What was it ? And have included a link to bjptools. Correct?? Sorry if the links are f-ed.

http://transact.dl.sourceforge.net/sourceforge/uhexen2/Quake-HOWTO.html
http://downloads.sourceforge.net/uhexen2/Quake-HOWTO.html?modtime=1226289266&big_mirror=0 

Quest.

http://quest-ed.sourceforge.net/

bjptools link is correct, should probably go on shubhub or something... Don't know if those compile hexen2 stuff!

The FTE engine also runs NQ stuff and even Nehahra... even in software. That could be a valuable tip for many. Amazing engine, seems to have evdev mouse issues for me though.

Nothing about QC coding, modelling and texture making? I'll see if I can help you there, good FAQ! 

You simply cannot optimize Java code for all platforms by making assumptions about the VM. You can only really optimize by reading the specs carefully and by good programming. The VM does a lot of optimization for you anyway, so whenever you think you've done something clever, the VM might just remove it ;-). Java is not a language for tasks that need a lot of clever optimization IMO.

Look at LWJGL for example, namely their math package. They use a clumsy design for mutable / immutable objects and direct field access, thus breaking some design principles because they measured the performance of dfa against property accessors and came to the result that the former is faster. We tested this on different platforms and had entirely different results. There's just no point in this. 

I don't really know about the lwjgl math lib, but the JME guys were doing stuff in their math libs that looked questionable to me.

Turns out my profiling shows they're right, on both linux and windows, on two entirely different machines. (both sun vm though, but i guess 99% of my users will use that.)

The changes i made after profiling sped up my game a LOT. Again, on both machines.

Your POV just doesn't seem very 'real world' (at least in the games world) to me. 

to clear things up: of course i'm coding all stuff up first (with performance in mind, but not doing any low level optimisations) and then check where the bottle necks are. Imho you get a pretty good idea of what parts you can optimise (and how you do it) that way. And it's the 'real world' way, especially if you test on several systems.

Btw, your argument "cannot optimize ... code for all platforms" is true for ALL languages, and still it's pretty.. common to optimise c++, isn't it? that's with even MORE variety in the underlying architectures, etc. 

Someone should fix up NPRQuake. It's pretty cool. For me.. mileage with the different renderers varies. I used to have "ainpr" working, but it's busted now. ... might do it one day. 

it was a cool idea, but didn't have the long-term maintenance and polish of some other engines. I think it was just a proof of concept made for a university class or something. 

It's actually pretty easy to create the dlls that create new renderers for NPR, so I encourage people to check it out. I managed to modify the blueprint renderer so that the randomly selected edges to be arrowed/numbered weren't randomly reselected each frame, which got rid of so much flicker. The actual code I used was an enormous hack, but the result seemed better to me, and I can see how someone would code it correctly now... 

FTE has some modes like this. And I think some other engine too (QMB?). 

I tried compiling FTE from CVS yesterday...
Maybe i'm doing something wrong, but "make gl-rel" needed plenty of niggles fixed. At linking i got bored and gave up when it spewed
[linking]
./release/gl_linux/pr_csqc.o: In function CSQC_StartSound':
pr_csqc.c:(.text+0x30e7): undefined reference o `PR_TempString
pr_csqc.c:(.text+0x3174): undefined reference to `PR_TempString
etc x 100