Slashdot Mirror
First Person Shooter - Under 100KBs of Code
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)."
amazing
While it is impressive to write something like this in such a small binary, the "Application" as a whole is MUCH larger. The obvious dependancy on DirectX alone makes the entire app > 20MB.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Sure would be nice if programmers around the world would at least follow this guys lead a little bit. I'm so sick of bloated software. For example - CD Writing software for windows. Does anyone need or even want all the dang crap that comes in those?
Don't Tread on Me
Suddenly, I'm taken back to the days of Doom, where I can fit a FPS onto a floppy disk. Sweet.
relying upon Mesa, the nv driver, and the linux kernel would be any better? It would still weigh in over a meg then.
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)
So they've optimized it down so amazingly well the zip fits in 96kb, but the thing still needs half a Gb of memory to run? Interesting.
Personally, I'd rather go for a 512Mb package that runs on a 96kb box, but I'm odd like that.
"I Know You Are But What Am I?"
I know you are being funny, but this program seems fairly DirectX dependent. Maybe if it was OpenGL?
This thing is a feat of programming, but its small size belies that fact that it requires a mammoth rig. Procedural textures? Great if you want to needlessly minimize your software so it will fit on exactly the kinds of devices that won't be able to run it.
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.
This game is dynamically linked to DirectX, which is a large program library. 3D Winamp visualizations are also small, because they don't have much rendering code in them either, but they're also not optimized very well (like a *real* engine such as Quake 3 or UT2004). Just because *your* "hello, world" is statically linked to the C++ library and mine isn't, doesn't make mine better because it's smaller.
And procedural textures? The demo scene guys have been doing this for ages.
This has left me underwhelmed.
Vote for global prefs bug
> so, what does this really advance?
:)
/. posts reek of techno-ludditeness (-luddetery?) to me.
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
(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 and JetPac?
HD space is cheap right? So if this advancement increases development time and cost, it is a tech achievement, but... i guess... whats the point?
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.
Have you actually read the source code to that thing? I downloaded it out of curiousity, here's a tidbit of the main() function:
...
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.
Like woodworking? Build your own picture frames.
nt
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
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
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
The fact that it is only 96kB is really nothing to laud, considering that most assembly programmers could fit a basic raytracer in under 4k of code - provided that all textures and layouts were read from disk.
So the fact that they fitted all the textures and layouts into the other 92kB is "nothing to laud"?
Play FarCry then But dont complain if you get shot while admiring the view
Raytracing? What exactly have you smoked?
.kkrieger audio programmer .de
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 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?
The society for a thought-free internet welcomes you.
... that every alien spaceship/moonbase/post-WWIII Earth is devoid of the technology to do LIGHTS?!?
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 - Where dreams and software unite
K&G Arcade - 26 games in one, a unique blend of action, adventure and humor
Invasion: Trivia! - Trivia, with a very sick twist!
Electro - The premiere electronics tool for PocketPC
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Well, this is rather disappointing. The game works with neither wine (transgaming CVS build) or winex3 (prebuilt binaries). You'd think that something this simple would run. I wish, I wish I hadn't paid that stupid fee to transgaming. I'm canceling my subscription to them as the CVS build works better for me anyhow.
Raytracing has absolutely nothing to do with wireframes. Maybe you're thinking of 'raycasting', which is similar but still not the same. But then you start talking about rendering the scene back-to-front, which has nothing to do with either technique.
"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
Jesus was a liberal
like a *real* engine such as Quake 3 or UT2004
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.
The ______ Agenda
This isn't just a demo, it's fucking art. Nothing short of art.
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.