C or Assembler for game development

[Heaven/TQA]

still not get why above example should be used for cc65. as there is few steps needed to write the same in assembler?

 

never touched cc65 though but I would prefer Action! then... on Lynx most people seem to use cc65.... but that beast is 4mhz...

[baktra]

still not get why above example should be used for cc65. as there is few steps needed to write the same in assembler?

 

never touched cc65 though but I would prefer Action! then... on Lynx most people seem to use cc65.... but that beast is 4mhz...

I should have written the VBI routine in assembler. Corrected now. The idea is to minimize number of assembler statements in the code.

[Irgendwer]

This is a strange thread with strange arguments.

 

* People write/wrote games in Atari Basic - also good ones. Maybe the execution speed of a programming language isn't always important to be able to develop a game?

* There is (hopefully) no doubt that cc65 is faster than Basic. This could mean that the range of games with a sufficient runtime performance is even bigger?

* Premature optimization is the root of all evil (D. Knuth). Could mean "Why should I mess around with assembler even on non-critical parts of my code (performance wise) while I could use more readable & easier/faster producible code?"

 

So why not start with cc65 to produce a game and change later only the performance critical parts?

 

Regarding the "VBI-sync problem": Many problems of the kind "I like to update visualizations while not visible" are solvable by deferring the change of the register to a specific VCOUNT value. Busy wait for the desired value and change e.g. the HPOS register, PM-base or do a page flip to have a tearing free visualization without any VBI. If you loose a frame, your code would be to slow in VBI too...

Edited February 4, 2017 by Irgendwer

[twh/f2]

Fully agree Christian!!

 

I think implementing a game should be as efficient as possible because that way somebody can spend much more thoughts on the game and it's balance . I hate to struggle with bloat code and confusing endless lines of three letter acronyms.

 

greetings,

twh

[zzip]

This is a strange thread with strange arguments.

 

* People write/wrote games in Atari Basic - also good ones. Maybe the execution speed of a programming language isn't always important to be able to develop a game?

* There is (hopefully) no doubt that cc65 is faster than Basic. This could mean that the range of games with a sufficient runtime performance is even bigger?

* Premature optimization is the root of all evil (D. Knuth). Could mean "Why should I mess around with assembler even on non-critical parts of my code (performance wise) while I could use more readable & easier/faster producible code?"

 

So why not start with cc65 to produce a game and change later only the performance critical parts?

 

 

My concern is more about code size rather than execution speed. I have no doubts CC65 far outperforms basic. On these 8-bit systems, every byte counts

[flashjazzcat]

Exactly so. Code produced via pure assembly is usually (or always) the last to consume all available RAM. It depends on the project, but one way or another, code size will eventually become an issue.

[Irgendwer]

 

My concern is more about code size rather than execution speed. I have no doubts CC65 far outperforms basic. On these 8-bit systems, every byte counts

 

Surely the compiler output is likely to be bigger than hand-optimized assembler. But what is hand-optimized assembler? Creating huge tables to trade memory for speed? Putting even little common parts into functions to trade speed for memory?

The same is true for cc65: Depending on your style you can trade things.

In my programs the biggest parts are taken by data (fonts, graphics, PMG, levels, music, sound), and even if cc65 would produce code 3 times bigger than "hand-optimized assembler" the by far smallest part is inflated then.

 

 

Theory aside, here a little example how 'effective' you can code in cc65 (if you like):

#include <atari.h>

void
main(void)
{
  do
  {
    GTIA_WRITE.colpf2 = ANTIC.vcount;
  }
  while(1);
}

Is compiled to (cc65 -t atari -O2 test.c):

;
; File generated by cc65 v 2.15
;
	.fopt		compiler,"cc65 v 2.15"
	.setcpu		"6502"
	.smart		on
	.autoimport	on
	.case		on
	.debuginfo	off
	.importzp	sp, sreg, regsave, regbank
	.importzp	tmp1, tmp2, tmp3, tmp4, ptr1, ptr2, ptr3, ptr4
	.macpack	longbranch
	.forceimport	__STARTUP__
	.export		_main

; ---------------------------------------------------------------
; void __near__ main (void)
; ---------------------------------------------------------------

.segment	"CODE"

.proc	_main: near

.segment	"CODE"

L000A:	lda     $D40B
	sta     $D018
	jmp     L000A

.endproc

Due to the C (stack etc.) initialization the resulting program is 527 bytes in size, but this base size is needed only once.

The core code would be even longer in basic tokens, beside that the output cannot be reached due to the timing:

 

Basic:

 

cc65:

color.xex