Lightmaps: THE shit!

Hey hey hey, I had that awesome idea a week ago. Lightmaps! You know - all these fancy big static shadows every 3D game has and had. Even the earliest ones used it and it's still a core part of all modern 3D games. I realised it would be impossible to have a realtime-calculated sun that moves around on bigger maps, so I decided to implement lightmaps into my game renderer. It looks like this atm (night time screenshot):

And it's fucking fast for a raytraced game! The next step is implement an interpolation between two lightmaps. But why? Yep, that's a good question! If there's a sun and a moon - both moving around - I can actually have a day/night cycle with some awesome shadows in realtime! I just need to calculate a lot of lightmaps with different sun/moon positions and everything will work with interpolation between these two lightmaps (smooth!). Holy shit, I haven't expected that my game will ever reach a global light source without slowdowns. Damn, I need to make a video of it - it looks much better in motion. There are even shadows for all moving objects and no framedrops, yet!


Ok, ok. Maybe I'm overrating all these... erm, well.. archievements! It took me some days to get it work correctly, but it was worthwhile! I hope I can finish the interpolation until the Berlin Indie Game Jam (BIG) starts. I also need a tile editor, but this could take a while! Damnit, I wish I had more time to code an editor. Well - a little demonstration doesn't need awesome maps, eh? I know I can do a lot with different ASCII characters.

Let's get back to work - there's a lot to do... 1 day until Friday! I'm so damn excited!


Shooting again


A bit different this time. Now you can clearly see the blue shadow int the middle, the @ is our hero, flying over these big blocks. The little smile is an enemy on the ground... Hard to notice without depth, I know.

More Screenshots


Two more screenshots to test luminous objects and layered light sources. Also, I want to integrate interpolated (ingame day time-based) shadow maps to simulate real sun light. Two little extra alghorithms, some pre-calculations and several sun/moon light positions. Sheesh, I feel so frigging awesome! Great stuff in my head.


First Screenshots


Early screenshots from my sandbox level with an improved/reworked terminal font. The renderer is done so far and I don't think that it needs more updates. Now it's also possible to move things which can get reflected after hitting a wall. Next steps are:
  • Clean up the prototype code, make classes out of it
  • Implement gravity
  • Movement vector-affecting material calculation (hardness, etc)
  • Create AI table system/apply old 1D game idea
  • Map/Game Editor
I fear the last two points. The first is technically a simple thing but needs a better implementation than in my 1D game prototype. It's an object AI depending on a bunch tables and state values. It's more logic than anything else - not to say the most important part of every game. So, the second point is really a lot of work. I thought about implementing an ingame-editor like the one used in Cube 2: Sauerbraten. This is the best and simplest thing ever because coding a completely new project just for adding the stuff I already did in my prototype would be stupid and too work-heavy. A lot of professional games use off-game editors but I'm sure this isn't a good investment. I have several good ideas for different tile draw modes and so on... Let's see if it works like I thought. Maybe I can also add a complete ingame AI editor! Maybe, maybe...

It's written in the stars, I just need to read it.


Korg DS-10

The Korg DS-10 is a virtual analogue synthesizer for the Nintendo DS. My module arrived some days ago and it's a pretty awesome little sequencer with 6 similar but different build-in synthesizers. There are a lot infos about the DS-10, google it! This is what I wrote on the TIGSource Forums:
After approximately one month delay, my DS-10 arrived.

And this little box is even more awesome than I thought before. It's basically a very simple (not to say primitive) pattern sequencer. 18 song slots, 16 patterns for a song and max. 16 bars in a pattern. There are two freely adjustable synthesizers for leads, 4 drum synths of the same type with crippled ADSR envelope, but all 6 six synths are LFO patchable and whatever not. The 4 drum synths can have there own effect on each channel, a seperate fx unit can be applied to synth1, synth2, synth1+synth2, the drum part or everything. It's a bit tricky to add not-that-analogish-sounds, but can be done. The cool thing is: You can modify every drum channel for having multiple bass lines or acidish sounds. The two Kaoss pads are very cool, you can set values/variables for each axis. The pads also have different scales if necessary - like arabian or egypt which is imho a big plus (I prefer simplified scales). Every synth setting/preset can be saved/loaded independent from song file (30 slots if I remember correctly). So, there is enough memory to store a short videogame soundtrack.

The first real audio impression was pretty good - fat sound, good and clean quality. It's hard to make it sound bad. Editing patterns is nice but lacks comfort like shifting notes inside the pattern up/down/left/right. This can get improved. I also wonder why I can't copy my patterns with more comfort. It's stil a simple drum machine, the song mode just for making records and pre-structured tracks, I guess... The DS-10 is more a tool for experimentation/freestyle composition and/or live performances. It's possible to produce all songs by editing single notes (questionable because there are two Kaoss pads for live recording).

All in all a good and cheap analogue synth with limited editing comfort. If you're not into synthesizers, the DS-10 may be a bit annoying and/or disappointing. Geeky stuff! I love it!
So, there is not much wrong about it - you can produce quality-sounding music in a fast and simple way. A little demonstration of mine how it can sound:

"Trance (DS-10)" recorded with Audacity

DS-10 can delivers a great variety of synth sounds suitable for lots of electronic music styles, so don't mind the simplicity of my track! Youtube offers a number of nice tracks done with the DS-10, it's a live performance beast. You can also link multiple DS-10s via WiFi connection to archieve more channels/sounds/patterns/etc... Fucking cool.


Demolition Man

This movie is so fucking awesome!

I wonder why I haven't watched it before.


Your time is running out, foolish object!

So I started working on game objects. Objects/entities/whatever in other games are usually models/sprites with a position, acceleration, size and/or bounding box. In my earlier games and thoughts I always tried to use delta values and motion vectors for movement and just everything. But recently I had the nice idea of skipping all delta values but using delay-based timers for movement. In my game, the minimal movement is 1 pixel/character/symbol/tile. If I cut all bigger movements per frame into smaller steps (1-tile-movement) I can easily avoid expensive line geoemetry, rasterisation, etc... If the periodical timer check gets performed fast enough, I could reach a maximal speed of 1000 tiles per second! But that's a) unnecessary and b) unlikely. If a graphical frame delay requires up to 16 milliseconds, the maximum movement speed per axis would be 62,5 tiles per second - which isn't that nice, especially for highspeed bullets or somewhat fast objects. So, the only way to get around this is a) a high timer resolution (but how?) or b) floating-point based step values by time delta division (delay time between last timer check divided by step delay/inversed step frequency). I'm currently implementing way b. It's the most accurate variant and still simple to implement. And it's probably not that slow. Even if there's a float division, it's only required for highspeed objects. The bad things that I need to rasterize the resulting way between original_position and new_position... This is bothering me! But hey - I did tons of line rasterizers. Shouldn't be a problem. But if I think further, movement vectors would require the same strategy. So... wouldn't it be the same by implementing movement vectors? Hm. The timer version is good for slow stuff, the movement vector isn't. Also, the timer version is very accurate in cases of framedrops, hm...

Time implement both of them.