Starting from your title, this is nowhere near "fair". First of all, it is "Commodore".
Second, while M.O.O.D. is one of the productions that is closer to being a Wolfenstein 3D clone on C64, it does not represent the best rendering possible. There are at least a few others on C64 that employ better rendering, albeit they are simply demos and would not be considered as playable games (just like mine here). If I am supposed to give some names; One-Der, Living, Brutal Comeback, some Resource demos and a Smash Design demo come to mind at first thought.
While I appreciate Project-M, the comparison you are trying to do here is like comparing apples and oranges. You take the best effort in Atari world and compare it to some production in C64 world that you think is the best, while it is actually not (technically and aesthetic wise).
Lastly, one has to wonder why it was obligatory to bring C64 vs. Atari topic under a size limited raycaster feature. Probably, the long time itch of Atarians losing against C64 25+ years ago came alive again. Right.
Yes, as I wrote also on Pouet, you can use/distribute it. I just ask you to kindly mention in your app that this was done by Crescent, as due to size restriction, it is not mentioned anywhere in the actual demo. Thank you!
And that is exactly what 1bir does on C64, i.e. redefining a char in set and filling the screen with that char. Then all it does is to change color RAM nybbles to "render" the scene. In that regard, what I reffered to as "video RAM" mistakenly above was actually supposed to be color RAM.
I think, porting to VIC20 should not take more than changing some addresses and making the rendering code to work with VIC20 KERNAL, if there are differences with C64 KERNAL. Also it would be a 22x22 screen matrix, instead of 40x24 as it is for C64 now.
Next version is coming up soon, with more features than you actually mentioned in your post.:-) (It will not be under 256 bytes, though). This was, as you said, made to prove that it can be done under 256 bytes. Therefore, the size limit does not really allow to add many more features than there are now (although it is still possible to add small improvements here and there, of course). Lastly, this does not utilize any LUT, except for the usual sine/cosine tables.
It is quite possible that it will run on VIC20, but it will probably need some modification to the actual render code (I do not have a VIC20, so I am not sure). Other than that, it should work, as RAM usage is minimal (just needs 320 bytes for sine/cosine tables, ZeroPage and the 1K video RAM).
Nevertheless, I will include it in the next release. Thanks for the idea.
(Save this as a.prg file and run it in your favourite C64 emulator or on the real thing itself. Please note that the first two bytes are actually required by.prg file format to indicate load address. The actual code is 11 bytes).
Slashdot Mirror
Starting from your title, this is nowhere near "fair". First of all, it is "Commodore".
Second, while M.O.O.D. is one of the productions that is closer to being a Wolfenstein 3D clone on C64, it does not represent the best rendering possible. There are at least a few others on C64 that employ better rendering, albeit they are simply demos and would not be considered as playable games (just like mine here). If I am supposed to give some names; One-Der, Living, Brutal Comeback, some Resource demos and a Smash Design demo come to mind at first thought.
While I appreciate Project-M, the comparison you are trying to do here is like comparing apples and oranges. You take the best effort in Atari world and compare it to some production in C64 world that you think is the best, while it is actually not (technically and aesthetic wise).
Lastly, one has to wonder why it was obligatory to bring C64 vs. Atari topic under a size limited raycaster feature. Probably, the long time itch of Atarians losing against C64 25+ years ago came alive again. Right.
Yes, as I wrote also on Pouet, you can use/distribute it. I just ask you to kindly mention in your app that this was done by Crescent, as due to size restriction, it is not mentioned anywhere in the actual demo. Thank you!
And that is exactly what 1bir does on C64, i.e. redefining a char in set and filling the screen with that char. Then all it does is to change color RAM nybbles to "render" the scene. In that regard, what I reffered to as "video RAM" mistakenly above was actually supposed to be color RAM.
I think, porting to VIC20 should not take more than changing some addresses and making the rendering code to work with VIC20 KERNAL, if there are differences with C64 KERNAL. Also it would be a 22x22 screen matrix, instead of 40x24 as it is for C64 now.
Next version is coming up soon, with more features than you actually mentioned in your post. :-) (It will not be under 256 bytes, though). This was, as you said, made to prove that it can be done under 256 bytes. Therefore, the size limit does not really allow to add many more features than there are now (although it is still possible to add small improvements here and there, of course). Lastly, this does not utilize any LUT, except for the usual sine/cosine tables.
Well spotted, I missed that one out. :-) Usual problem of looking at the same thing for so long, now it perplexes me how I missed such an easy one. :-)
It is quite possible that it will run on VIC20, but it will probably need some modification to the actual render code (I do not have a VIC20, so I am not sure). Other than that, it should work, as RAM usage is minimal (just needs 320 bytes for sine/cosine tables, ZeroPage and the 1K video RAM).
Nevertheless, I will include it in the next release. Thanks for the idea.
The alternative version (1bir-alt.prg/s) uses no illegal opcodes at all. :-)
The Vimeo link in the story somehow became broken, the correct link is as follows:
http://vimeo.com/66004524
Here is a 13 bytes version in 6502 machine code:
7C 00 20 D2 FF A1 85 29 01 E9 92 D0 F5
(Save this as a .prg file and run it in your favourite C64 emulator or on the real thing itself. Please note that the first two bytes are actually required by .prg file format to indicate load address. The actual code is 11 bytes).
For more information:
http://pouet.net/prod.php?which=60810