Did you change the map or the code?
I see no strange effects now, works perfect.
works great on my home computer, you’ve really done well to capture the OutRun/RoadRash feel.
I changed the map AND the code, but it’s mostly the code that caused the improvement 
Here’s a new screenshot with some added scenery (this version is not online yet though):
haha nice it looks much better
nice, much better now… works on archlinux with awesome and r300 open source driver 
fullscreen is working fine
now populate it with some cars and make it playable!
happy to see it finished
cheers, kulpae
Please don’t scramble my desktop again
http://indiespot.net/files/temp/scan_corrupt.png
Vista 64 bit, Java 6u21.
It ‘worked’ but it wasn’t pretty. Looked like 8 bit dithering: you can see the bit-patterns if you look closely.
Care to share your FSEM code?
I didn’t check bitdepth in my init code, could you try again?
http://www.gagaplay.com/scanrace.jnlp
(This version also has some scenery)
Actually I’m thinking of moving the engine to LWJGL; it’s probably quite easy to do and will allow me for a lot more eye candy ‘for free’. Getting a bit bored of all the manual performance sapping pixel fiddling
work perfect here : Java 1.6u221 / IE9-Vista / intel dual core 2.2Ghz
Works here too now.
For those interested, this latest version now also draws everything front-to-back using a z-buffer to minimize overdraw.
However, max performance on my laptop is now about 85 frames per second, which is getting awfully close to the target 60fps. The sprites alone made the maximum frame rate drop from 90-95 to 80-85, and there’s not really that many sprites currently. There’s some room for optimization in the sprite drawing, but still, I’d like to add loads more eye candy. For example translucency (shadows, explosions, nicer looking edges, maybe even some lens flare), I need to add background graphics (sky & horizon), a hud overlay… And I want V-Sync! So I guess I will really need to switch to OpenGL for this.
It will still retain the same quasi-3D quality of the current engine (for example, you never really turn; the shifting of road lines just make it seem that way), and much of the current scaling calculations are actually real 3D transformations already, so it will keep the same ‘old school’ over-the-top feel (screw realism, I want SPEED ;D).
You could also try porting your current algorithms to OpenCL and using OpenGL only for blitting the final image to the framebuffer. It would be interesting, but it kinda minimizes your target audience (not sure what your plan for this is).
How about doing the rendering on multiple cores?
I just want an Outrun kind of game (or perhaps Road Blasters).
I’m not very familiar with OpenCL; what could that bring me extra with this?
It would be nice if (in the end) it would be portable to Android too, if I’m able to make a fun game out of this.
Yes, I guess it would be not too difficult to multi-thread this for multiple cores. But I also kind of have a second core reserved for doing the sound and music using my SoftSynth library. Doing all rendering in software would leave me with a feeling that I waste CPU power doing stuff that a GPU would be doing better. What would be good reasons to do everything in software?
[quote]What would be good reasons to do everything in software?
[/quote]
More compatible? But I guess its not really a big deal these days. Most computers can run openGL fine.
more fun and less headhack
IMO, if you dont requiere OpenGL dont use it, and if you think it is requiered for performance issues use it, but you may just abstract your rendering process so you will stay free of change its implementation later if you wish ( or even provide both ).
[quote]But I also kind of have a second core reserved for doing the sound and music using my SoftSynth library
[/quote]
this is probably not using a lot of CPU, you should be able to still multithread mass data computation for your rendering
sidenote:
yes most computer can but … count number of problem with java-opengl and count number of problem without (software run almost 100% well).
OpenCL lets you write a piece of code once that:
- runs on multiple platforms.
- runs on either CPU or GPU without changes.
- runs on multiple threads automatically, as in each thread solves part of the problem (fork-join). Threads = cores for CPUs, Stream processors/Cuda cores/etc for GPUs.
- gets vectorized automatically (e.g. uses SSE/SSE2/etc on CPUs, vector math on GPUs)
- runs efficiently in general, because the compiler has full knowledge of your data structures, their types, memory alignments, etc.
OpenCL can also efficiently share data with OpenGL and other APIs (even D3D).
The downsides:
- You need to learn a new API and language (though it’s basically C and very similar to GLSL if you have experience with that).
- Current implementations are immature. That means bugs, portability problems, performance gotchas, etc.
- It isn’t supported on all platforms and very few users have working implementations installed. Afaik iPhone does have OpenCL support, not sure about Android.
Obviously the last 2 downsides are going to be fixed in the near future, but it’s a risk.
[quote](software run almost 100% well).
[/quote]
…until you try to go full-screen 
I think OpenGL is reliable enough to not leave the shedloads of GPU power unused.
OpenCL sounds quite interesting, however I’m not sure if it would be the right tool for something like an old-school racer. Sounds like it could be great for full blown 3D renderers and ray-tracers and such.
yes, that depend on what exotic/buggy function you use unfortunatly lot of Java API are unreliable 
( give applet focus before each F5 press ), ok ok this is not a real exclusive fullscreen…