Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Egghead ! (Registered 2020-11-28) You are not logged in 
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: 408
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: 993
@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: 1093
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
Groepaz

Registered: Dec 2001
Posts: 9646
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: 993
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:
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: 191
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: 1093
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: 993
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: 480
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: 3028
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
ibux/Artline Designs..
Soya/Censor Design
DRAX/Maniacs of Noise
anonym/padua
SKR/ONS/sidD/STARZ
Guests online: 99
Top Demos
1 Coma Light 13  (9.6)
2 Uncensored  (9.6)
3 Memento Mori  (9.6)
4 Edge of Disgrace  (9.6)
5 Unboxed  (9.6)
6 Comaland 100%  (9.6)
7 Lunatico  (9.6)
8 The Shores of Reflec..  (9.5)
9 Rivalry  (9.5)
10 X Marks the Spot  (9.5)
Top onefile Demos
1 Copper Booze  (9.9)
2 Quadrants  (9.6)
3 Elite Code Mechanics  (9.6)
4 Square Booze  (9.6)
5 Hedge of Disgrace - ..  (9.6)
6 Dawnfall V1.1  (9.5)
7 Smile to the Sky  (9.5)
8 Daah, Those Acid Pil..  (9.5)
9 Crystal Gazer  (9.4)
10 Instinct  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Censor Design  (9.4)
3 Oxyron  (9.3)
4 PriorArt  (9.3)
5 Triad  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Horizon  (9.9)
3 Stormbringer  (9.7)
4 Fungus  (9.5)
5 Moloch  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.04 sec.