| |
Nightlord
Registered: Jan 2003
Posts: 131 |
Release id #112378 : Coma Light 13
now that we all had watched this many times, I wanted to ask if the authors can give a bit more info on the technical side of things. The demo has a really entertaining notefile but coders want more detail, so that we know what exactly we need to beat :)
For instance is the shadow casting vector realtime, or the dualpyramid with the 4 circles attached to its vertices. is that realtime?
Thanks again for a great demo.
|
|
... 24 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Just needed to do some forensics, and found that the loader version/configuration string was nulled.
Really, if you need to go into these depths of "optimisation", you're doing it wrong and your cruncher sucks. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
How though? Whatever isnt needed, gets deleted. And "loader identification string" qualifies for this for sure :) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Oh well, i did hide some version numbers in the code at some point, precisely because of this lame thinking. =)
(And yes, it is needed once in a while (re: forensics), just not for the demo to run.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
> Oh well, i did hide some version numbers in the code at some point, precisely because of this lame thinking. =)
So basically disassembling the binary blob and then kill what shouldnt be there is still needed - thanks for the hint :) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
You're obviously trolling, and the source is still open, but setting a few single bytes here and there to... something else will most likely not provide any crunching gain to speak of. =) (If that's what you're after.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
Not trolling at all - disassembling the binary blob and then optimizing it for my needs is what i do, i am faster at that than what it would take to understand the macromessoverkill to do the same with the original source (and AFAIK its also what bitbreaker did before he made his own thing). Its also easier to integrate that way (because i am not using ca65 for anything demoish) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
You failed so far to show me a better way of achieving the multi-platform/multi-drive support without macros, and they're generally not used just for the sake of using them.
Also you don't assemble SID tunes for your demos yourself, do you?
The loader is just another library, like SID tunes are, and is supposed to be linked as binaries anyways when you're not using ca65. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
Quote:You failed so far to show me a better way of achieving the multi-platform/multi-drive support without macros
why would i? demo is runnung on c64, with 1541. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
I was referring to the loader code with its "macromessoverkill". C-64 and 1541 are not its only targets. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Back then even more memory got wasted, like with a script that was resident and loading the respective parts. $200 bytes are enough for everyone and i still stick to it. As for assembling SID tunes, there's SDI with TASS-source if you need to relocate /o\ I don't see any problem in nulling out the version number, nor would i waste any byte for it, nor did i wipe it out :-D Afaik it was a ported version that was working with acme back then, and i guess anything that was not needed was simply thrown out. Because one could as the main reason :-D |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
