| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Advanced C64 Gameprogramming Manifesto
Advanced C64 Gameprogramming Manifesto
A kind of minirant, not informative enough to be included on the BitOps site but I hope this raises some thoughts, or even flames (considering the mild scene-bashing :) ) Originally posted on Lemon64 scene forum but I thought I'd post here too...
An advanced C64 game could contain:
- Sophisticated AI system (it is good enough when entirely CPU-controlled "battles" between two or more factions can be staged, and it looks good)
- Scripting language for controlling storytelling & action; running on virtual machine(s)
- Dynamic memory allocation, for example dynamic allocation of spritedata
- Loadable code modules; each module can have "methods" that can be called (a bit like object oriented programming)
- Challenge yourself!
- Push all limits!
- Forget oldskool traditions and limits, if they're not useful!
- Remember that during C64's early times, games adhering to these "advanced" principles were written (for example Maniac Mansion ). The "scene" approach usually forgets this pioneering work, focusing on graphical & aural excellence and code optimization while ideas & theory are very limited!
- Gathering experience on other platforms, or of computer science in general, and applying it on C64 can produce devastating results!
( Enhanced Newcomer definitely fits under Advanced Gameprogramming :) ) |
|
... 15 posts hidden. Click here to view all posts....
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
I think dc.b and dc.w etc. are a tradition from 68000 assemblers.
But Richard, don't worry about that VM asm code example, here's something even worse to look at:
8000 pushism 01
8001 storabs 7f
8003 pushimm 0a
8005 pushabs 7f
8007 islt
8008 jfalse 0a (8012)
800a pushimm fa
800c storabs 7e
800e incabs 7f
8010 jump f3 (8003)
8012 stop
Code for a virtual stackmachine (quite Java-VM-like, in fact) Though it's not meant to be generated by hand, but with a compiler instead :) |
| |
6R6
Registered: Feb 2002
Posts: 244 |
Cadaver,
really nice that Rant page of yours.
explaining sprite sorting and stuff. :)
Write more please.
-grg-
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
I will hopefully write more about interpolated movement and frame skipping. But first I should get the MW4 stack-machine working 100% :) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Got inspired suddenly...
Rant #11: Frameskipping, interpolation & re-entrant IRQ code
http://www.student.oulu.fi/~loorni/covert/rants/interp.htm |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Hey, I just uploaded my 1k minigame, which is a data-driven engine. Animations are scripted, graphics are made out of independent pieces which are heirarchically connected in chains, etc. Actually, I found that it's far more flexible, memory-efficient, and just plain easier to write if you have 1 big code routine for handling general cases, and letting the data define specifics, as opposed to having a bunch of little code snippets scattered around, each handling a special case. In the data-driven case, adding new functionality is just plugging more data into the tables, instead of writing, calling, and linking new code.
BTW: I've been a software engineer for almost 10 years, doing advanced OO and r&d, and I fully see the application of the high-end principles for small systems, as well as having the 8-bit upbringing to know when to bit-twiddle a nice ugly hacked optimization into the code. :)
minigame: Invasion of the Color Clashed Graphics |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
OMG! That game nearly made me shit my pants :)
That, if something, is 100% Advanced Gameprogramming. And the char-accuracy movement (not bad looking at all) made me think of software-sprite engines... |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Quote: OMG! That game nearly made me shit my pants :)
That, if something, is 100% Advanced Gameprogramming. And the char-accuracy movement (not bad looking at all) made me think of software-sprite engines...
...that's because it *is* a software-sprite engine. :) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Quote: ...that's because it *is* a software-sprite engine. :)
Yes, naturally :)
But it made me think of other applications, mainly on a bitmap screen... |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Quote: Hey, I just uploaded my 1k minigame, which is a data-driven engine. Animations are scripted, graphics are made out of independent pieces which are heirarchically connected in chains, etc. Actually, I found that it's far more flexible, memory-efficient, and just plain easier to write if you have 1 big code routine for handling general cases, and letting the data define specifics, as opposed to having a bunch of little code snippets scattered around, each handling a special case. In the data-driven case, adding new functionality is just plugging more data into the tables, instead of writing, calling, and linking new code.
BTW: I've been a software engineer for almost 10 years, doing advanced OO and r&d, and I fully see the application of the high-end principles for small systems, as well as having the 8-bit upbringing to know when to bit-twiddle a nice ugly hacked optimization into the code. :)
minigame: Invasion of the Color Clashed Graphics
Ah, I just wrote my first "completely" data-driven musicroutine. Player code is only about $280 bytes and still it can achieve almost any imaginable effect. "Instrument data" consists only of a pointer to a "program" which can then include various commands to set the voice playing, pulse modulating etc. These commands can also exist in the pattern (sector) data. There is no predefined, hardcoded behaviour for example hard-restart, which is kind of cool I think.
Currently takes a little under 16 rasterlines, though it still has to be optimized... |
| |
Viktor
Account closed
Registered: Apr 2002
Posts: 78 |
I am decoding the Infocom Z*code interpreter. It uses the virtal machine idea.
Viktor |
| Previous - 1 | 2 | 3 - Next |
