Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user NthSt4r ! (Registered 2025-05-17) You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > A Simple Commodore 64 Game in C++17
2016-09-26 12:34
Martin Piper

Registered: Nov 2007
Posts: 739
A Simple Commodore 64 Game in C++17

CppCon 2016: Jason Turner Β“Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17Β”

https://www.youtube.com/watch?v=zBkNBP00wJE

Rather interesting to watch the compiler in action from: https://youtu.be/zBkNBP00wJE?t=747
 
... 6 posts hidden. Click here to view all posts....
 
2016-09-26 17:22
MagerValp

Registered: Dec 2001
Posts: 1082
@Mr. SID: It added hard limitations and a fun demo. C64 light saber pong is a lot more interesting than some modern 8-bit microcontroller board.

@JackAsser: That was indeed the best question, pity he didn't answer it. One forgotten const or changed optimization and your code explodes.
2016-09-27 07:54
ChristopherJam

Registered: Aug 2004
Posts: 1423
The use of 32bit x86 as an IR was an interesting decision. I wonder if there are any 16 bit llvm targets that would have been a better fit? Admittedly the x86 code generator's probably the most mature at this stage.
2016-09-27 08:51
chatGPZ

Registered: Dec 2001
Posts: 11499
both gcc and llvm backend are targetted at 32bit CPUs.... and all the hacks that try to generate 16 or even 8bit code are really ugly, and result in really ugly code - thats why probably :)
2016-09-27 14:30
MagerValp

Registered: Dec 2001
Posts: 1082
ARM support is also mature and battle tested, and I would've thought that thumb would be better suited as IR on the way to 6502. Still, for the purpose of the talk i386 worked just as well.
2016-09-27 14:44
Mr. SID

Registered: Jan 2003
Posts: 425
I guess that's not helpful because:
Quote:

Thumb has all the advantages of a 32-bit core:
32-bit address space
32-bit registers
32-bit shifter, and Arithmetic Logic Unit (ALU)
32-bit memory transfer.

Only the opcodes are 16bit, so you still have all the same problems you have on x86.
2016-09-27 14:48
Peacemaker

Registered: Sep 2004
Posts: 279
grrr. fuck you commodore, why didnt you make this machine 32bit? so c++ would be more useable :(
2016-09-27 17:49
ChristopherJam

Registered: Aug 2004
Posts: 1423
Quote: grrr. fuck you commodore, why didnt you make this machine 32bit? so c++ would be more useable :(

πŸ˜‚πŸ˜‚πŸ˜‚
2016-09-27 18:10
MagerValp

Registered: Dec 2001
Posts: 1082
Quoting Mr. SID
Only the opcodes are 16bit, so you still have all the same problems you have on x86.


Well except the ARM instruction set is actually sane :)
2020-04-18 19:03
TWW

Registered: Jul 2009
Posts: 549
I watched the presentation and got inspired to code this manually.

However the original contained some things I wanted to improve and still see if the result (size / # of instructions) could match the compiler. These are the points which were improved:

- start with RUN command OR autorun (added)
- No clear screen when stared (Implemented)
- Border color not set (Implemented)
- Use full screen size instead of 256 pixels (9 bit arithmics vs 8 bit) (Implemented)
- Ball getting stuck bug when bouncing off a player if it still has collision detected. (Fixed)
- Decimal score to 99 (Implemented)
- Limit player top & bottom (min/max Y) (Fixed)
- 1 player sprite-colour not set (same as background) (Fixed)
- Reset both ball and player position after a miss. (Implemented)
- Cosmetic - moved the score away from the screen centre (Implemented)

The result ended up as follows (original values obtained from the presentation):

Original x86 (No idea of the compiled size):
- Compiled: 83 x86 instructions - excluding boilerplate (graphics)
- Compiled: 231 x86 instructions total incl. gfx

Compiled: 419 x6510 instructions total
- 126 bytes of graphics written => 2 instructions each byte = 252
- 419 - 252 = 167 instructions for gamecode (estimated)
compiled: 1005 bytes (6510)
- Graphics = 5 x 126 = 630b
- 1005 - 630 = 375 bytes without graphics (estimated).

After adding the improvements above I ended up with:

hand coded Size excl. gfx: 301 bytes vs 375 bytes
hand coded size Incl. gfx: 390 bytes vs 1005 bytes
hand coded excl. gfx: 115 Instructions vs 167 Instructions
hand coded incl. gfx: 139 Instructions vs 419 Instructions

At least some improvement. Actually only 32 instructions more than the x86 version looking only at the game code.
2020-04-19 11:39
hedning

Registered: Mar 2009
Posts: 4775
A Simple Commodore 64 Game in C++17
Previous - 1 | 2 - 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
Technotron/I-I F
Kronos/Arsenic/FC
Dr. Doom/RAD
Guests online: 79
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.6)
4 Coma Light 13  (9.6)
5 Codeboys & Endians  (9.6)
6 Edge of Disgrace  (9.6)
7 Signal Carnival  (9.6)
8 Comaland 100%  (9.6)
9 What Is The Matrix 2  (9.6)
10 Uncensored  (9.6)
Top onefile Demos
1 Scan and Spin  (10)
2 At the Cinema  (9.8)
3 Nine  (9.8)
4 Layers  (9.6)
5 Cubic Dream  (9.6)
6 Party Elk 2  (9.6)
7 Datastiltje 2014 Win..  (9.5)
8 Copper Booze  (9.5)
9 Onscreen 5k  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Artline Designs  (9.4)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Performers  (9.3)
5 Censor Design  (9.3)
Top Cover Designers
1 Duce  (9.8)
2 Electric  (9.8)
3 Junkie  (9.6)
4 The Elegance  (9.5)
5 Mermaid  (9.3)

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