Saturday, 5 December 2009

Be Selfish



It's funny! When I loaded this WAD, I had the feeling of a double deja vu. I thought I have played this before twice, the second time wondering if I had played this before. For some reason it appeared three times in my hard disk (normally, I download new WADs and put them in a directory, later I delete them or put onto favorites. Now, this one appeared for a third time in my WADs to play dir).

Yet it was so nice that I wasn't bored to play it for a third time. I am even inspired now to continue creating some old levels I started making months ago.

I love Paul Corfiatis levels. They just have the right balance of gameplay, design, architecture and size. Levels with excessive details are interesting, although when you can create atmospheric worlds with more simplistic geometry yet still enough detailed then it's a must. I like minimalistic worlds that inspire me to imagine that I am in there. I like interesting architecture. I also like a kind of gameplay that is not too hard yet it provides enough action. And sometimes few sets of interesting traps. Other WADs overdo it with detail (which is interesting though or nice to look at) and difficulty (this one is not interesting, just annoying).

I've just seen that enough time has passed since I last posted something about a doom wad, yet there are quite more good ones that I should one day review. I just love playing doom wads and especially taking nice pictures of interesting looking spaces and writting reviews about.

Little moods of coding.

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..

Friday, 4 December 2009

About demo limitations

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 :)

Thursday, 3 December 2009

My new Dingoo has arrived!


Dingoo.

First impressions? Surely it's not as good as the Wiz (but I already knew that and the price is lower anyway) but I am quite happy with the new device. What I like is that in contrast with the Wiz, it's coming with several emulators (GBA, NeoGeo, Capcom System 1,2, NES, Mega Drive, SNES) integrated in the menu and you don't even run the emulators, you just select a rom and it runs directly the same way you would run an application or native game for the machine. It comes with more games seemingly made from the company who made Dingoo, few of them aren't that bad, like a 3d alone in the dark/resident evil style game called 7 days. And the 3d engine is quite good (also, software rendered, no 3d accelerator on the device) and is also used in few more games provided by Dingoo games division.

What might be better than the Wiz is the fact that the battery time is quite nice (7 hours or more) and what additional it has that the Wiz might miss is there is also a radio. A TV-out port is also on the device and even a cable is provided in the box (I am not sure if the wiz has tv-out but it seriously didn't come with the box. Also, what is enjoyful is the vast amount of Chinglish (all your base are belong to us :) both in the manual, website and game menu. Firmware is Fureware, Video is Wideo, also there are two options with funny names, '3D Game' (to run any APP files, from games to applications) and 'Interesting Game' (to run emulator roms). Just funny.

I also tried the official devkit for windows. It uses their own SDK (s2dsdk) that was maybe used for the developing of their own games. It's quite object oriented and I had to use to send pixel objects to the framebuffer which maybe does some inner conversion because a simple rendering proved to be not as fast compare with everything else I have tried. I'd like to see if there is a more low level to access the frame buffer. Many people have moved to Dingux which is a linux port for Dingoo and a lot of released emulators and ports of games require Dingux (which is unfortunate if you haven't installed it yet and you want to run regular Dingoo APP files, you find not many stuff). I had problems with mounting the device in Vista but in an XP laptop it worked just fine. I also had problems updating the firmware (there is an official and an unofficial from homebrew devs, most people prefer the unofficial). I hope Dingux doesn't need a new firmware to be installed..

I also managed to compile something for the Gamepark Wiz under windows. Originally I had installed Ubuntu to compile with the linux devkit (there is no good Wiz Devkit for Windows yet :P) but I gave a modified devkitGP2X a third try under windows and this time I succeeded. I get very good framerates. And it's all SDL. So easy to port!