First Person Shooter - Under 100KBs of Code 741
Cariad Ilmara writes "For those of you old-timers who spent days & nights trying to get your code fit into 64Kb, here's the first beta of .the .produkkt's next FPS: .kkrieger. Moderately beautiful, what's impressive is it can fit inside the UT2004 readme. The demo is 96Kb zipped. All textures are procedural and generated at startup. Screenshots available
here, here, here, here, and here. You still need a relatively recent computer (~1.4Ghz, 512MB RAM) and a DirectX8 GPU (Windows required)."
wow (Score:3, Insightful)
Libraries (Score:1, Insightful)
Sure would be nice (Score:4, Insightful)
Wow (Score:2, Insightful)
in that case (Score:5, Insightful)
Do we only impress the critics when we write to bare metal?
(of course not, because then you're criticized for having hardware lock-in. You just can't win)
err, great. I think. (Score:2, Insightful)
Personally, I'd rather go for a 512Mb package that runs on a 96kb box, but I'm odd like that.
Re:awesome... now only if they'd do this for linux (Score:3, Insightful)
size belies necessary hardware (Score:2, Insightful)
Re:System Requirements (Score:2, Insightful)
It's simple why you need a semi-powerful machine to play this. It generates the textures at startup. I'm assuming it'd take a pretty powerful machine to generate textures like these screenshots, with such small code to work with in the first place.
As a comparison. Think of SETI@HOME. A very very very small file. Yet, it can take 4 hours or more to process on what is considered a fast machine. Same dealio with this.
100KB, please (Score:4, Insightful)
And procedural textures? The demo scene guys have been doing this for ages.
This has left me underwhelmed.
Re:Libraries (Score:5, Insightful)
Re:so, what does this really advance? (Score:2, Insightful)
Their claim to m4d sk1llz?
I remember a time when posters on slashdot enjoyed tech coolness for the sake of coolness. I'm probably growing old and grumpy, but lately too many
Re:while I am impressed at the code size... (Score:3, Insightful)
(And yes, being a suspicious puppy, I did look at the network traffic while it was starting up just in case it was downloading on the fly...)
But 64K? Pah! There were more fun games in 16K - I mean, who can forget 3D Monster Maze [the-underdogs.org] and JetPac [worldofspectrum.org]?
Re:so, what does this really advance? (Score:3, Insightful)
The point is not the size, features or technological advance at all. It's just sort of a proof-of-concept, if you like. It doesn't do rendering on it's own, nor does it have support for various graphic chips (all that is provided by DirectX), but it does have its own engine and all the model data and textures (mind you, it still includes all the textures although they are procedural, it just means that they are in forms of functions). And that is impressive.
Can't try it myself yet, but I'm already amazed. Btw, to those who wonder where's the source etc, these things are usually not handed out. Demo/intro scene is more about competing with each other and the secret's of the trade are not given away!
People pointing out DirectX dependency are missing the point.
Re:Sure would be nice (Score:1, Insightful)
If it's a commercial game, it's going to ship on a CD-ROM, or more and more on DVD-ROM these days (like UT2k4).
I don't care if the coders stayed up all night coming up with the worlds tiniest collision detection algorithm, hand assembled. (Bad example, the DirectX API and ultimately the GPU does stuff like that, but anyways).
I really don't care if the textures are procedural or compressed bitmaps. Actually, do I want to wait 20 minutes for the game to compute all textures at startup? Nope, I'd rather have static data ready to go. I hate load times. Especially on a hard level where you die every 30 seconds and have to wait 5 minutes for it to recreate the world.
You can save the code-bloat arguments for another topic, like the kernel or web browser. I just like to play fun games. I have 200gb of space to install 'em on. It's not a big deal.
It's impressive how small they managed to make this thing, but really, who gives a shit? Tiny code might make for a better browser or word processor, but it wont make it a fun game.
Re:2K raytracer (Score:5, Insightful)
int main (void) {
char b[99];
int W=GN,H=GN,i,n;
nl=GN;ns=GN;
_f x,y;
F(nl) RP(LI)
F(ns) {RP(SI.c) SI.r=GN; RP(SI.l) SI.f=GN;}
char* s = new char[(n=W*H*3)];
memset(s,0,n);
PT p={0,0,CZ},q={0,0,0},c;
Skipped the class on "meaningful variable names," did we?
While a 2K raytracer is marginally impressive, a 5K raytracer with readable source code would be far MORE impressive, IMHO.
Re:Libraries (Score:2, Insightful)
Right! It reminds me of the business of creating N-ingredient recipes (3-ingredient or 4-ingredient, typically): the trick is to define as many things as possible as "staples" (salt, flour, butter, sugar), so that the ingredients can be "salmon, oregano, and bread crumbs" or something.
But just like the N-ingredient case, it's not really cheating. People really are likely to have those things already in their kitchen, and people really are likely to have the supporting libraries around their hard drive. And any attempt to optimize for size has a certain appeal in these days of increasingly bloated code.
You know far cry? (Score:2, Insightful)
Re:Sure would be nice (Score:5, Insightful)
It pretty much depends on what the code does as well. If you have a
really cool way of computing the normals of thousands of polygons in 10
lines of code, that might be _alot_ slower than a great algorithm doing it in 100 lines.
By your argument, the code in the story should run 100'ds of times faster than any of the recent commercial FPS games..
Re:Libraries (Score:3, Insightful)
Re:Sure would be nice (Score:3, Insightful)
Lets see, Golden Hawks [goldenhawk.com] CDR software comes in at 688k. Cant realy see them getting much smaller then that. Then again, if you can't handel a 688k program, what are the odds you have a use for a CDR drive?
Re:Sure would be nice (Score:2, Insightful)
Statically linked binaries are a tad faster than dynamic ones.
Pixel shader effects are SLOW. Look at Halo PC as an example, and all of the bitching from gamers about "how shitty they ported it". The GPU has to do maybe 200 times the work per pixel.
Using static arrays, prerendered graphics (whats faster, raytracing the pieces for your chess game on the fly, or using some premade bitmaps) speeds things up.
How about an example from something I wrote, back in the day of 486s that didnt necessarily have a FPU..
It was a 3D app for a class project, a goldfish swimming around in a tank. I wanted his fins and tail to 'ripple' in sort of an undulating way. I figured the best way to do it would be to offset some of the vertexes, following a sine wave over time.
So, first I wrote something like this:
for (each fin)
for (each vertex)
yoffset = yoffset + sin(t + (180 * VertexNumber));
That approach worked, sort of, the fins moved like I wanted them too. The binary was tiny, since the sin function lives elsewhere. But it was slow as hell, especially on machines with no FPU.
What I went with was a lookup table, like this:
Create an array of 1080 entries (so I could follow sin's to a quarter degree)
Fill the array with values of the sin function
Replace calls to sin() with a simple array lookup.
It was orders of magnitude faster. Of course, the running size was larger with a big array of floats. Startup time still bothered me, so I eventually put the entire array of values into a header, which made the code much larger.
You would call it bloat if all you looked at was code size, but I got an A because mine was the only fish with wiggly fins who rendered (in software mesa on el cheapo lab machines circa 1996) in realtime with 8 independent lights rotating around him (also thanks to my sin lookup table). He did backflips too.
Re:I would be more impressed... (Score:5, Insightful)
That 96k contains all the scene data. It isn't just the engine. Why would you be impressed if they wrote their own graphic engine? How would you take advantage of hardware accelleration. Sheesh! Write a tight program that uses OpenGL/DirectX and you get criticized for not using assembly tuned to bare metal. Write aseembly tuned to bare metal and you get criticized for having a program that only runs on specific hardware (or doesn't take advantage of hardware acceleration).
-matthew
Re:I would be more impressed... (Score:1, Insightful)
So the fact that they fitted all the textures and layouts into the other 92kB is "nothing to laud"?
Re:Why are they all set in dark machine rooms? (Score:2, Insightful)
Re:Sure would be nice (Score:5, Insightful)
Re:Sure would be nice (Score:5, Insightful)
Re:in that case (Score:3, Insightful)
No, you impress the critics when you write a kick-ass FPS that I can play on my pile of 486s.
I mean, it's cool and everything that the program is small... I'm not going to knock anyone for doing something simply "because they can". But what's the point of making a program that fits on a floppy when most modern computers meeting the requirments don't even ship with floppy drives anymore?
Re:I would be more impressed... (Score:5, Insightful)
I won't allow myself the time to dismiss your "arguments" on a detailed level, but:
* Why is the game SO dependent on the graphics card then?
* Why do you talk about missing lighting effects when there's a full phong lighting model with several light sources and stencil shadows everywhere?
* Why do you think you know ANYTHING of the used algorithms? Did you already reverse engineer the whole game?
* Timer interrupts? ON WINDOWS? Come on.
Please. "I have no idea how this all works, but I hate them" would really have been less hassle to type
kb / farbrausch
game programmer at Inverse Entertainment,
I'll sum up (Score:3, Insightful)
I post this in reply to a few of the responses I've gotten, not just the parent post.
- I'm not impressed with the 96kB executable size. As far as executables go, it is small for a Windows app, but it still dwarfs the animated demos which have a limit of 4k.
- It seems to me that the point of writing this game was not to produce the smallest useful binary, but rather to illustrate a particular method of reducing binary size by producing textures at runtime rather than compile-time.
That said, the real story is not the size of the executable, but rather the value of the tradeoffs made to produce it. I don't find this particularly remarkable. The coders made a tradeoff; they exchanged a smaller exe size for a lower runtime performance. So what? How is this any different from what every other coder has had to do at one point in their career?I wish these guys had actually made the exe larger, because /. would focus instead on the technique used to compress the textures, rather than its small size. Maybe instead, someone would comment on how the 96kB exe actually runs faster because the whole executable image resides in the processor's cache?
Why is it... (Score:3, Insightful)
I am impressed by anyone that can get a 3D engine into that small a piece of code. You can make the argument that because it's linked to DX that it's actually hundreds of megs large. I don't agree... I could then make the claim that EVERY piece of software that makes use of an OS's API calls is really hundreds of megs big. That's clearly a bogus argument, and I don't think linking to a given library nullifies this achievement.
But still... Can we get some LIGHTING in that thing?!? Doesn't even have to be dynamic, I'd be perfectly happy if you increased the overall gamma a bit. I mean, the graphics, what I can see of them, look excellent, Why not bring them out in the light more?!?
*
Omnytex Technologies [omnytex.com] - Where dreams and software unite
K&G Arcade [kgarcade.com] - 26 games in one, a unique blend of action, adventure and humor
Invasion: Trivia! [invasiontrivia.com] - Trivia, with a very sick twist!
Electro [omnytex.com] - The premiere electronics tool for PocketPC
Doesn't work w/ wine or winex3 (Score:2, Insightful)
Re:Sure would be nice (Score:4, Insightful)
Will all games be this size? Do the games need to fit on a floppy? No, but a happy medium would be nice. It just seems odd that Microsoft bloated their OS with all this stuff that no one seems to fully utilize and developers, because they don't use the OS to its potential, bloat their software further.
Maybe I am easily amused, but either way what these guys did was impressive
Re:Libraries (Score:3, Insightful)
Re:Sure would be nice (Score:3, Insightful)
Wrong. Computing a texture from a few input params can often be faster than loading it from disk. (The disk-based texture is probably in a compressed format, PNG prehaps, so it'll also take computation to load, beyond the actual IO delay)
Many recent FPS games have horrendously slow load times (50 sec even on a powerful PC) due mainly to all the high-res textures. This is especially bad if you're loading straight from optical disc (as with a Playstation2)
Re:I'll sum up (Score:2, Insightful)
2. AI engine
3. 3D engine with collision detection, mesh animation, mesh generation from simple primitives...
4. Software music synthesizer as used in the Candytron and
This is an extremely interesting production for its size. Just look at the textures. So it uses DX8, oh no. Go download the Heaven Seven demo if you want a software raytraced demo in 64kb. This is a game, not a demo.
Also, it won't run on Linux. Not everything has to run on Linux. This was made for windows. Windows has the best gaming and 3D support out there, Linux doesn't come close. If you wanted to play games, then why the hell do you run Linux? Linux is for work. And please don't cite a ton of games that have been ported to lux. The demoscene has always been for Windows/DOS only on the PC scene, since Windows is the best way to get the max out of gfx and audio hardware without compromising performance. It's just done better I'm afraid. I hope linux catches up someday, but the best way for it to do that would be to have MS port directx to it.
Re:Sure would be nice (Score:2, Insightful)
After all, most code out there is properly engineered, with all of the planning done up front, with requirements defined at the beginning of the project and remaining the same through the end.
It isn't like games get tweaked or redesigned daily, as people on the team realize what is fun and what isn't.
Re:Sure would be nice (Score:3, Insightful)
Of course, textures themselves are a poor substitute for dynamically generated geometry, in most cases. If you're looking at a brick wall, there's the texture of the actual bricks (each physical brick), and that's best handled with procedural textures. Then there's the interlocking nature of the bricks themselves, with the mortar, which is optimally handled by dynamic geometry generation or depth maps.
Smooth interpolation between bitmap -> procedural -> geometry texturing is where we'll end up eventually. Shader languages are the way to go.
Re:wow (Score:5, Insightful)
Re:Sure would be nice (Score:4, Insightful)
Re:Sure would be nice (Score:2, Insightful)
A cellphone with a CPU of ~1.4Ghz, 512MB RAM and a DirectX8 GPU?
Re:I would be more impressed... (Score:3, Insightful)
"Chaining the timer interrupt" is like something I'd say if I were interested in making something sound more complicated than it really is to someone who had no idea what I was talking about. Besides that, you don't get timer interrupts in Windows programming (nor any other protected-mode operating system, I'd assume).
Based on those 2 things, I'd assume that you've got no clue what you're talking about. And how does an 81-byte fractal program compare in any way to a primitive 3d game engine?
--Jeremy
Re:I'll sum up (Score:3, Insightful)
A *real* engine? (Score:3, Insightful)
Hello Mr. Clueless-modded-insightful. What is listed as a requirement for Quake 3? That's right, Open GL. UT2004 doesn't explicitly require DirectX9.0b if you're willing to run in software emulation mode, but don't kid yourself and try it without. And since when does a static linking to DirectX9 take 5 CD's?
Games take a lot of space because they are full of detailed 3d animated models, extra-large textures, and lots of sound and music. None of that comes from DirectX. These guys have managed to use some cool tricks to create detailed models and images on par with a lot of what is released today and do so in under 100k. That's pretty darned impressive.
If your "Hello World" is dynamically linked to a C++ library, and mine procedurally generates a novel titled "Hello World" of comparable quality to a Tom Clancy book, my "Hello World" is just cooler.
Of course, mr. Repugnant_Shit, you are a troll. But someone modded you up for reasons unknown, and as such a little explanation was in order.
This is art. (Score:3, Insightful)
These guys consistently put together tightly coded, artistics pieces of material that not a single contributor to this discussion could have done no matter how long they had available to them.
Yes, they used DirectX. Who cares. No, the game isn't a commercial effort. But it's tiny. And it looks awesome. And on good enough hardware it runs perfectly.
This is the programming equivalent of carving a portrait into the top of a needle.
So what if it doesn't run on Linux. Who said it was supposed to? It doesn't use OpenGL, that's their personal choice. Just respect it for the phenomenal level of expertise required to produce something like this. For the innovation, skill and effort they must have poured into 96KB of data.
Personally, I'd love to come close to this level of skill in anything, let alone something this difficult.