Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > CSDb Discussions > Advanced C64 Gameprogramming Manifesto
2002-04-24 02:10
cadaver

Registered: Feb 2002
Posts: 1160
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....
 
2002-05-03 17:19
Viktor
Account closed

Registered: Apr 2002
Posts: 78
And what do you think about the JVM (Java Virtual Machine)?
You can read about on the Lunix mailing list.
(There are on the net some small JVM (32k large) and some people talks about it to converting)

bye.
Viktor
2002-05-03 18:02
cadaver

Registered: Feb 2002
Posts: 1160
Well, really interesting to see on the C64 :) but I'm afraid it'll be a bit slow. An amazing feat nevertheless. An action-game oriented virtual machine could be very simple, and fast, containing mostly directly game-oriented commands & instructions, like

(example code for an enemy in hypothetical script language)

if (player.distance < VERY_CLOSE)
say("Halt, intruder!");
attack(player);
endif




2002-05-03 18:14
cadaver

Registered: Feb 2002
Posts: 1160
Note that of course it's no use using a virtual machine/script language setup just for the sake of it, if it can't bring some kind of benefit, for example less memory use.

That above operation done directly in ASM
ldy #INDEX_PLAYER
jsr get_distance
cmp #VERY_CLOSE
bcs no_alert
lda #<alert_message
ldy #>alert_message
jsr say
jsr attack
no_alert:

would take 19 bytes.

In a hypothetical bytecode, that the hypothetical virtual machine would interpret, it could be for example:

dc.b SET_FOCUS,INDEX_PLAYER
dc.b GET_DISTANCE
dc.b COMPARE_A,VERY_CLOSE
dc.b BRANCH_GT
dc.w no_alert
dc.b SAY
dc.w alert_message
dc.b ATTACK
no_alert:

that would take 12 bytes (slightly less)
2002-05-12 20:50
Richard

Registered: Dec 2001
Posts: 621
Quote: Note that of course it's no use using a virtual machine/script language setup just for the sake of it, if it can't bring some kind of benefit, for example less memory use.

That above operation done directly in ASM
ldy #INDEX_PLAYER
jsr get_distance
cmp #VERY_CLOSE
bcs no_alert
lda #<alert_message
ldy #>alert_message
jsr say
jsr attack
no_alert:

would take 19 bytes.

In a hypothetical bytecode, that the hypothetical virtual machine would interpret, it could be for example:

dc.b SET_FOCUS,INDEX_PLAYER
dc.b GET_DISTANCE
dc.b COMPARE_A,VERY_CLOSE
dc.b BRANCH_GT
dc.w no_alert
dc.b SAY
dc.w alert_message
dc.b ATTACK
no_alert:

that would take 12 bytes (slightly less)


What sort of asm is this code referring to? It does not look like the sort of assembler I always use.
2002-05-12 21:31
cadaver

Registered: Feb 2002
Posts: 1160
That's the whole idea, it is an imaginary language which a C64 ASM routine will interpret. The point is to create your own language which suits the purposes best! In Metal Warrior 3 for example I used a script language for conversations and initializing the levels, but it can be used also for much more (actual action scenes)
2002-06-16 20:50
Richard

Registered: Dec 2001
Posts: 621
Quote: That's the whole idea, it is an imaginary language which a C64 ASM routine will interpret. The point is to create your own language which suits the purposes best! In Metal Warrior 3 for example I used a script language for conversations and initializing the levels, but it can be used also for much more (actual action scenes)

That will be a new thing for me to learn :)

....but I prefer Turbo assembler :)
2002-06-17 00:58
cadaver

Registered: Feb 2002
Posts: 1160
Now I'm just in the process of implementing the virtual machine system for MW4... But in roughly 99% of C64 game projects such system is not needed!

2002-06-20 22:58
RaveGuru

Registered: Apr 2002
Posts: 43
One of the most impressive games on the C64 imho must be Laser Squad. It's directly compareable with the Amiga and PC version. It contains great gameplay, advanced AI and decent graphics. I can't figure how they've squeezed allt that in on less than 64kb :)
2002-06-26 13:26
CyberBrain
Administrator

Posts: 392
Quote: What sort of asm is this code referring to? It does not look like the sort of assembler I always use.


If you're talking about the "dc.b"-thing it means the same in DASM as ".byte" does in turboassembler (or so i've been told). And "dc.w" means the same as ".word" does in turboassembler.

("dc.b" means 'declare byte')
("dc.w" means 'declare word')

(dunno why the DASM-coder thought it was fun to replace ".byte" and ".word" with "dc.b" and "dc.w", but he did)
2002-06-26 22:51
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
Quote:
If you're talking about the "dc.b"-thing it means the same in DASM as ".byte" does in turboassembler (or so i've been told). And "dc.w" means the same as ".word" does in turboassembler.

("dc.b" means 'declare byte')
("dc.w" means 'declare word')

(dunno why the DASM-coder thought it was fun to replace ".byte" and ".word" with "dc.b" and "dc.w", but he did)


i don't know if it's a matter of replacing them as such, just a matter of adopting a different standard; Zeus 64 has DFB and DFW commands if memory serves (never used the latter =-) and i'm fairly sure i've seen dc.b and dc.w on another assembler...
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Edhellon/Resource
lotus_skylight
Andreas/SHAPE
Krill/Plush
Sage/Skylight Designs
CA$H/TRiAD
ciccior2003/HF
JEZ
Guests online: 94
Top Demos
1 Next Level  (9.7)
2 Codeboys & Endians  (9.7)
3 13:37  (9.7)
4 Coma Light 13  (9.6)
5 Mojo  (9.6)
6 Edge of Disgrace  (9.6)
7 Fünfzig 90%  (9.6)
8 Uncensored  (9.6)
9 What Is The Matrix 2  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Nine  (9.7)
2 Layers  (9.6)
3 Party Elk 2  (9.6)
4 Charflasher  (9.6)
5 Cubic Dream  (9.6)
6 Copper Booze  (9.6)
7 Libertongo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Ten  (9.5)
10 Rainbow Connection  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Booze Design  (9.3)
3 Performers  (9.3)
4 Censor Design  (9.2)
5 Triad  (9.2)
Top Logo Graphicians
1 t0m3000  (10)
2 Sander  (9.8)
3 Mermaid  (9.5)
4 Shine  (9.4)
5 Facet  (9.4)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.061 sec.