64k intro C++ code
category: general [glöplog]
It depends on what would you like to do. See, after all these years C64 is still used, someone might want to use XM within 64k's too :).
I meant on PC :P But good point anyways :)
Quote:
What Decipher said. I've always done all hardcoding, too...that helps.
In 2007 Waffle and I coded a cute little 40k called Purple, which was really quite easy to get this small. We worked to add bytes in the end, not take them away :)
The point I'm trying to make is really you shouldn't worry that much about code size in 64k, it's data you're really gonna have to worry about.
And about D3DX, read the specific compo rules. Quite alot of compo's allow it nowadays.
I know, but I have couple of ideas how to generate a lot of data with very small input set, but to do that I will need pile of code :) And I want to make sure I will fit this pile into 64k.
Quote:
in general id say; dont focus on code until the very last. it doesn't matter if you dont do anything extremely silly. focus on how you mangle data for sounds and graphics (including 3d).
Design of this production is very procedural-3d-by-deforming-primitives friendly ;]
Quote:
Hatikvah is right. Code optimizing at the 64k level really isn't that much of an issue compared to the size of your compressed data.
Also, with music, 64k's used to customarily use MiniFMOD and .xm files with small samples. This compressed well but didn't sound that great as compared to the more recent synthesizer approach, which is much more common nowadays. I think at this point the MiniFMOD thing might be completely phased out (someone correct me if I'm wrong here).
I planned to go with softsynth approach.
I agree with Hatikvah, better to focus on how you will handle and compress the data you will use: music, geometry, steps to generate the textures, effects and so on, instead of the code itself.
Once you'll have everything working you could just go throw your code and do changes to get it fit into 64k if neccesary. It will be much easier and faster than to try to control everything from the beginning that will just end in lot of time and no production :)
Btw I was changing the compiler from VS2003 to VS2008 and I got few troubles while compiling small my lastest projects, so maybe this could be useful for u too to get a little base to get starting:
http://kile.stravaganza.org/blog/post/compiler-options-for-small-executables
Once you'll have everything working you could just go throw your code and do changes to get it fit into 64k if neccesary. It will be much easier and faster than to try to control everything from the beginning that will just end in lot of time and no production :)
Btw I was changing the compiler from VS2003 to VS2008 and I got few troubles while compiling small my lastest projects, so maybe this could be useful for u too to get a little base to get starting:
http://kile.stravaganza.org/blog/post/compiler-options-for-small-executables
Quote:
I know, but I have couple of ideas how to generate a lot of data with very small input set, but to do that I will need pile of code :) And I want to make sure I will fit this pile into 64k.
Just run a few tests, your code couldn't be THAT big unless it was coded with no size concern whatsoever ;)
Quote:
I agree with Hatikvah, better to focus on how you will handle and compress the data you will use: music, geometry, steps to generate the textures, effects and so on, instead of the code itself.
Once you'll have everything working you could just go throw your code and do changes to get it fit into 64k if neccesary. It will be much easier and faster than to try to control everything from the beginning that will just end in lot of time and no production :)
I started with 3D engine, to see how much I can optimize for size, and I am pretty sure it will got to final production almost unchanged, so it is not wasted effort :) Texgen/meshgen/softsynth will be prototyped, since it's rather new for me.
Quote:
Btw I was changing the compiler from VS2003 to VS2008 and I got few troubles while compiling small my lastest projects, so maybe this could be useful for u too to get a little base to get starting:
http://kile.stravaganza.org/blog/post/compiler-options-for-small-executables
I developed my own set of compiler flags, and they are very similar(Base Address: 0x6000000 and favor small code), but thank you anyway :)
Correct version: (*except for* Base Address: 0x6000000 and favor small code)
Months ago, i see some screenshots from a 4k seminar. It was from intel demo competition or nvscene i dont remember. what was on the screenshots was some kind of 4k demo tool, that was used for making atrium demo. while it seems very interesting (werkzeugg for 4k) i never found any video or pdf about this seminar.
found it back :
http://demotrip.blogspot.com/2008/08/mentors-seminar.html
http://demotrip.blogspot.com/2008/08/mentors-seminar.html
That is very interesting, thank you :)
that was given at NVScene.
Somehow offtopic question: How much performance does IASetVertexBuffers cost in D3D10? In the other words, is packing large geometry dataset in small number of buffers reasonable in D3D10? Currently I use one vertex buffer for each geometry entity, if data is static I simply set this buffer and issue DrawIndexed, and if data is dynamic I use fixed-size ring buffer and discard it on predicted overflow, so for each entity I must do IASetVertexBuffers, Map/Unmap for morphing meshes and DrawIndexed/DrawIndexedInstanced. Alternatively I could create 2 big vertex buffers, one for static and one for dynamic data, so I would have to call IASetVertexBuffers only when switching from one type of geometry to another. So is the second solution, and saving input assembler calls worth it?
iq actually has some code snippets for preparing a 64k project in visual studio et al. check out his webpage
macaw: Yes, I saw it, he even published nice 64k and 4k framework :)
Can someone tell me where could I find video of mentor's seminar mentioned before(http://demotrip.blogspot.com/2008/08/mentors-seminar.html) please? I checked the demoscene.tv, scene.org file archive and googled for it, but with no result.
His 4k seminar from NVScene?
Yes, saddly, I can't find neither video nor slides from the presentation.
aizen: I asked Mentor himself, he said he doesn't have the slides or something like that. Maybe asking him kindly (read: until he gets bored of us) might prove useful!
Decipher: Well, that is a nice idea :D BTW, it's quite odd, most of the seminars from nvscene are uploaded to dtv, but this particular is not.
Something happened while recording that particular seminar, I can't quite recall what it was, but about half of it got completely fucked. So at least a good portion of it quite simply doesn't exist.
It's a shame, this particular seminar looked very interesting. Is the remaining half of the video accessible somewhere?
1: just a hint about templates and inlineing:
the key is to control where the inlineing stops. you need inlineing to get your code fast, but you want to stop inlineing when speed doesn't matter.
STL is not about control, it's about trusting the implementation. i would never trust the implementation to be any good for 64k. actually i would rather use c# than STL. (and i hate c#, if you havn't noticed).
2: optimizing code size
always optimize for compressed code size. get the latest (unofficial) version of kkrunchy and carefully analyse it's map file statistics. find out how long your code is AFTER compression, not before.
3: plan for a second try.
ever seen my first intro? I am quite famous for my intros, but my first intro was utter crap. i doubt anyone has ever seen it. my second intro was fr-08: .the .product. that was quite good i suppose. still, expect your first one to be crap. finishing something is more important than nailing it. once you finished something, you can draw from that experience and find the team to nail it.
P.S.: i just checked, and my first intro is on pouet, but since there is no video link it takes some serious skills to actually watch it, and if you do it is not worth the effort :-).
P.P.S: http://www.scene.org/file.php?file=%2Fparties%2F2005%2Fbreakpoint05%2Fseminars%2Fbp05_seminars_-_dierk_chaos_ohlerich_-_compilers_and_assembler_-_xvid.avi&fileinfo
the key is to control where the inlineing stops. you need inlineing to get your code fast, but you want to stop inlineing when speed doesn't matter.
STL is not about control, it's about trusting the implementation. i would never trust the implementation to be any good for 64k. actually i would rather use c# than STL. (and i hate c#, if you havn't noticed).
2: optimizing code size
always optimize for compressed code size. get the latest (unofficial) version of kkrunchy and carefully analyse it's map file statistics. find out how long your code is AFTER compression, not before.
3: plan for a second try.
ever seen my first intro? I am quite famous for my intros, but my first intro was utter crap. i doubt anyone has ever seen it. my second intro was fr-08: .the .product. that was quite good i suppose. still, expect your first one to be crap. finishing something is more important than nailing it. once you finished something, you can draw from that experience and find the team to nail it.
P.S.: i just checked, and my first intro is on pouet, but since there is no video link it takes some serious skills to actually watch it, and if you do it is not worth the effort :-).
P.P.S: http://www.scene.org/file.php?file=%2Fparties%2F2005%2Fbreakpoint05%2Fseminars%2Fbp05_seminars_-_dierk_chaos_ohlerich_-_compilers_and_assembler_-_xvid.avi&fileinfo
actually, all the unofficial kkrunchy versions don't have the mapfile analysis working. which is kinda why they're unofficial :)
Quote:
1: just a hint about templates and inlineing:
the key is to control where the inlineing stops. you need inlineing to get your code fast, but you want to stop inlineing when speed doesn't matter.
STL is not about control, it's about trusting the implementation. i would never trust the implementation to be any good for 64k. actually i would rather use c# than STL. (and i hate c#, if you havn't noticed).
And you're right. I solved this problem by implementing very simple void* - based container and using private inheritance to derrive actual templated class from it. This way I have only one copy of container code in executable file, and by using thin templated wrapper around it I have syntactic sugar for semi-elegant notation ;]
Quote:
I constantly check the map statistics, and it seems I overreacted at the beginning of development. Actually 64kb is _vast_ amount of space. And I realized that post-compression size matters the most :)
2: optimizing code size
always optimize for compressed code size. get the latest (unofficial) version of kkrunchy and carefully analyse it's map file statistics. find out how long your code is AFTER compression, not before.
Quote:
3: plan for a second try.
ever seen my first intro? I am quite famous for my intros, but my first intro was utter crap. i doubt anyone has ever seen it. my second intro was fr-08: .the .product. that was quite good i suppose. still, expect your first one to be crap. finishing something is more important than nailing it. once you finished something, you can draw from that experience and find the team to nail it.
"Plan One to Throw Away" principle? ;] I will take that advice, since I know from my experience it's very true, especially because writting 64k intro is basically exploratory programming for me.
Quote:
P.S.: i just checked, and my first intro is on pouet, but since there is no video link it takes some serious skills to actually watch it, and if you do it is not worth the effort :-).
It can't be *that* bad :P
Quote:
P.P.S: http://www.scene.org/file.php?file=%2Fparties%2F2005%2Fbreakpoint05%2Fseminars%2 Fbp05_seminars_-_dierk_chaos_ohlerich_-_compilers_and_assembler_-_xvid.avi&fi leinfo
Thank you.
Quote:
actually, all the unofficial kkrunchy versions don't have the mapfile analysis working. which is kinda why they're unofficial :)
I tested my code with both 0.23a and 0.23a2 but eee, I don't recall if map analisys works or not(at this point I payed more attention to postprocessed and name-demangled .map file generated by compiler).