Haha, I am in good rare mood for coding!
Funny, especially during the time I was supposed to work for my university assignments and not for personal fun projects. I don't know why I have so much mood for hobbyist coding right now (maybe I should do a demo?) but I hope it keeps that way. And I hope to finish my courseworks too in parallel (although some of them require coding too).
Ok, as you can see in another blog, I just got a dingoo and tried compiling something for it. Although my attention swifted to Wiz. It's funny, I had bought Wiz for months but I didn't tried to develop something on it because there wasn't a proper windows devkit. Later I installed Ubuntu just for that, although I didn't used it. Recently I read somewhere that actually, the older GP2X applications can run directly on Wiz sometimes, if the SDL libs are compiled dynamically. It's so compatible that games like Flesh Charmer just run in Wiz by trying to execute the old GP2X file. And 2x/3x times faster of course. Although the vast majority of GP2X apps are simply compiled statically (there was a problem with dynamically compiled apps, some didn't worked, maybe if you firmware was upgraded, so it was better to have SDL libs inside the executable even though the size was getting bigger for just a simple thing).
Anyways, I found out that the only thing you have to do is to use DevkitGP2X for the old GP2X to compile something with options for dynamically compilation and this will run perfectly on WIZ too (you also have something that is compatible with both the GP2X and the Wiz, wow!). And so I thought, when in the past I avoided getting into burden, that nowadays if I can compile GP2X stuff, it wouldn't be so hard to do it for Wiz too. I then found a devkit in a chinese site that installs a devkit on windows with an example and it does it automatically and also uses DevCPP and dual compilation, one windows that you can see the results on a window and one gp2x, so you could even take some old SDL code from PC, compile and run it properly on windows project and be sure that you could just compile it with gp2x switch and have it ready. It's so portable and easy that it makes me cry! I took a voxel plasma SDL effect I had done on PC and with almost no modification I had a gp2x version in fifteen minutes. Wow!
Then, I got some strange mood to start coding a new rasterizer. I had a discussion with a friend and I decided to start the new one from scratch even if with rasterizers it's scary because they are complex boring beasts. Normally I would avoid coding a new one especially if I lack motivation, but yesterday I had so much mood that I actually started. The focus here is to code carefully and try to make it as simple as possible. Because usually, my last ones were bloated. The very last unreleased version suffered from some bugs and still was big enough even if I wrote stuff in easier way and it was two times faster than the old on PC (haven't tried on GP2X or Wiz though). It also uses a way they say it's bad for the cache but I will just try and benchmark both versions on my Wiz or even GBA. My focus is to carefully make one as simple as possible at first (with only flat shading for the beginning), benchmark what is the best and gradually upgrade it. I want it to be a suitable simplistic and fast as possible rasterizer for old hardware, especially the very slow GBA. I want to make a very simple tiny 3d engine and not the last beast I was trying to make last time (very organised or bloated). Who knows, maybe I'll do a GBA demo with this one..
Ok, going back to? Damn,. I have to do courseworks for university..
Saturday, 5 December 2009
Friday, 4 December 2009
What do I like and what I don't:
- 256b: They are nice because it's a good opportunity to spare some time on the old good assembly. I used to advocate assembly coding in the past but today there is no way I am doing it again, not on PC, not even in gamepark handhelds, maybe not even on GBA (although I am curious about the speed improvements on the good old slow GBA). I am too lazy. But in 256b intros you have to do it. And usually a simple intro can be coded in 1-3 evenings. Also good for small demo releases. Unfortunately my new Vista don't run the 256b intros anymore and dosbox is too slow for the good ones.
- 4kb: Also an opportunity to make a fast release if you are lazy to code a big 64k or demo although this time you don't need assembly. With the various frameworks around the web, you can have a simple empty template in 700bytes and start from there. The negative is when size is too restrictive and you end up writting coding in different ways, inlining your function in one big ugly pile of code and generally screwing things up. Just so the compiler and cruncher gives you 20 missing bytes to reach exactly 4096 and not be at 4116 or something. I don't like this. Also, in 256b you have an excuse for not having any music (even a very bad and ugly music is considered a must) but in 4ks it's an additional burden for me. Especially when I have only the gfx and it's already 500 bytes below the limit and I know I can't crunch enough without removing scenes.
- 64k: The best of the best, even if one needs to work harder to create them and there is no excuse for and not having a music or having a shitty one (although you can just play a nifty chip tune that sounds cool and fits into something like 10kbs or 20 there). The interesting thing there is that there is enough space if you love to do everything procedurally. This is the most interesting part of all those tiny intros in my opinion. In 4ks, even if you did stuff procedurally, you would be very soon sort of space, just by code. But in 64k, you code and code and code stuff and you still can't reach the limit. I haven't code enough of them, maybe just because they need more effort. I have produced 256b and 4ks which I like less than 64ks for the same reason. 64ks is something to check in the future.
- Source limitations: I haven't seen one in the demoscene but when I was into the quickbasic forums, there were those compos where you had to write stuff fitting in 3 lines of code without semicolons and one had to write bloated pieces of code or reduces all his variables into single letters. I don't like killing my code just for source code size. It makes no sense. But this is just supposed to be a fun or senseless enjoyful competition. Even if it doesn't appeal to me. Also, similar methods are used into squeezing shader code for 4k intros.
- Graphics limitations: I am mainly thinking of ASCII demos. Each year there is a competition going on and each year I am thinking of maybe entering but I am not even starting to code something. It's fun to watch them but I am not motivated enough to code something like that, because it's just like reducing the resolution into something like 80*50(???) and coding the same effects. (Actually I have a ridiculously slow raytracer that would run perfectly smooth in that res ;) Ok, maybe there is a challenge, trying to do things look cool with text (because it's not just the resolution, it's also the character and color you will choose to shade your graphics differently). Actually, some graphics limitation compos are interesting. There was one at DBF interactive forum where you had to either have blocky pixels or 4 colors only or both, and I even made three entries for it. Sometimes it's fun!
- Hardware limitations: This is just very interesting to me. Someone will say, what's the meaning of limiting yourself, like when you have a PC, why try to code a raytracer on the C64 or something? Remember, I said before about 256b/4ks, if my extremely tiny programm is 257 bytes, why bothering with 1 byte? It's still extremely tiny and fully procedural so it's getting boring and senseless to kill those few bytes. But there it makes sense. You don't have a hard drive with only 256b free. You have plenty more. If your intro is 300bytes it won't matter for me. Ok, it's only for fun and senseless competition here. But the same doesn't exactly apply on hardware. You have the CPC and you want to work on the CPC and there 4Mhz Z80 is just what you have. Of course you can do the code on the PC, but your focus is to code something for a specific hardware. There is no even point to code it for an emulator that overclocks the machine since you want it to run on the real thing you have home and watch it and be proud of it. Although sometimes it can become too restrictive too. 8bits are too slow and you better code assembly there and their video modes are pretty weird and unfriendly. Opensource handhelds are my favorite hardware limit because they have a middle point of power, not too lame, not too fast, most coming without 3d accelerator, so it's like having an old 486 with 320*240 pixels of glory :)
- Other limitations: Imagination! Try to make out your own limitations or rules for demos. Shortest scrolltext? Longest maybe? Use a fucked up restricted palette and try to make something good out of it? Make a demo where only additions is allowed and no mul no div no sine no nothing? Make a demo out of a specific simple effect or routine? I would like to hear such compos around. Or maybe create some weird unofficial random rules for a demo I'd like to make and try this out (E.g. throw a D&D dice and determine that I should make a small demo with only plasma, glow and shade bobs, using that specific palette of 32 colors, each part shouldn't be longer than 5 seconds and the music should be a mix between trip hop and polka :)