forum.defence-force.org

Sizes cc65 vs (osdk):

_playerUpdate 3549 (7581)
_emenyLeftRightUpdate 1414 (3247)
_addObjectInEngine 81 (!?!) (3070)
_animator 1055 (2066)
_enemyUpDownUpdate 828 (1712)
_printKeysScreen 610 (1512)
_input 206 (1376)
_addObject 538 (1216)

Attached are sym+map files.

That's a crazy size reduction.

Is it somewhat possible to compile CC65 to assembler source code so I can compare the results with what LCC is generating?
I think Fabrice would be interested

Crazy and quite unexplainable, if you ask me. I can't see how this can happen, unless everything is implemented as subroutines, with the consequent waste of time.

Other big cuts to code size could be achieved by adding constraints to the compiler. If you don't allow recursion or limit the number or type of the parameters in functions, but I doubt that is the case here.

I am curious indeed

Well,

If you look at the code on GitHub, you can see there are quite a lot of functions, many of them taking many parameters, even including "int" parameters for some of them... Yet, cc65 seems to generate code that is both quite compact and fast. On the latter point if would be interesting as well to compare the relative speeds of the game compiled with cc65 and OSDK...

Now, if you look at functions like animator() (in src/engine.c), where the generated code is twice as big for OSDK, you see it is composed mainly of conditionals, dereferencing arrays with pointers, integer computations, and only 4 calls to the same "printBG()' functions, so it looks like the difference between cc65 and lcc65 (OSDK) may not necessarily be in the calling of functions, but maybe rather in the way conditionals, tests, pointer operations and arithmetics is implemented.

Obviously, to be able to see exactly where cc65 is more efficient than lcc65 we would need to be able to compare generated assembly codes, as DBug pointed out..

Another thought on this:

While searching the forum for some old topics about cc65 to gather some information, I came across this one: Questions to CC65 users

There is a very important piece of info in it, examplified in the first reply by iss in which he demonstrates that cc65 cleverly optimizes calculations involving char types to 8-bit arithmetics, even though the C standard mandates conversion to the int type for all integer calculations, which means calculations using 16-bit arithmetics at least should be used, as this is the smallest acceptable width for the 'int' type in the standard. See for instance this blog post: Deep C: Integer Promotion or this one: Integer promotions in C, and ponder the implications of this rule, especially for computations involving unsigned and signed variables...

Incidentally, I totally ignored this rule in the C standard until I was told by Fabrice F. the maintainer of the lcc compiler for the OSDK, while discussing code generation and optimization and problems I faced when trying to turn my small "Electr'Oric" game demo into a fully-fledged game, soon hitting memory limits for my compiled code. This was a shock to me at the time, because I thought well, what's the use of a C compiler for the 6502 if it generates verbose, unoptimized 16-bit arithmetic code for simple 8-bit calculations?? I also unfortunately discovered, as DBug had advised me, that the way to go to reclaim some memory was to do away with all function parameters and use global variables instead... This provided a huge memory gain, however there was no cure for the "16-bit calculations" problem...

Anyway, to wrap it up, I think this fundamental difference between cc65 and OSDK's lcc for handling 8-bit arithmetics may very well explain some (or even most) of the generated code size reduction between cc65 and lcc...

Wells, both compilers can generate assembly code so it would be nice to compare the output of one or two of those routines...

I can't do that now, I am on holiday but shouldn't be difficult.

Just seen this game - looks good.
Well done with the work so far.

Hi,
I had some free time and did a few more levels

Enjoy

trrerr wrote: ↑Mon Dec 02, 2019 12:12 am Hi,
I had some free time and did a few more levels

Enjoy

Hi there,

Thank you very much for adding new levels to your game, I downloaded the new version last week and finished the 4th level, it was awesome, you really have a gift for designing challenging levels, thank you! I'm now looking forward to tackling the last 2 levels!!

Also, I saw you added a new "bocco2" project on GitHUb, is it an evolution of the original bocco game? I cloned the repository and tried to load the .tap file in Oricutron, but it only changes the character font then the emulator hangs so I guess it's not finished yet!

Anyway, please keep going at it, I really enjoy your games, I also tried 'Sea Battle' and although I much prefer Bocco's adventures of course, it's still a nice little game that's really well crafted too, congratulations!

Hello retroric,
I'm glad you like what I did. I like the enthusiasm you talk about Bocco Adventures

For Bocco2Adventures, yes this will be a sequel to the roguelike style game. What you saw is a very early version. Unfortunately, memory is not enough for what I want to do, and now I'm looking for a way to do it. May I solve this problem.

The idea is rooms and several floors, including monsters and chests, items and spells.

Here are some screenshots of what has been done here:
This github repository is temporary and I will remove it. It spoiled the surprise .

I don't know exactly what will come out with this game

I have a few more projects started, and maybe after that I will continue with Bocco2Adventures.

Lovin' Roguelike games
I'll be happu to try this one, as your games are fantastic trrerr

Question: Are you making sure there's a clear version number indicated somewhere in the game?

Hi ,

coco.oric: I also hope to try it on this roguelike game.

Dbug: Тhe version is not described anywhere. Maybe I should put it in the disk name (for easier orientation). The game release versions can be retrieved from the github commits, but maybe you are not asking that. retroric came across repositories of a new game that is a sequel to this one. If I can finish it, it will be in a new git repository.

trrerr wrote: ↑Mon Dec 16, 2019 11:24 pm Dbug: Тhe version is not described anywhere. Maybe I should put it in the disk name (for easier orientation). The game release versions can be retrieved from the github commits, but maybe you are not asking that. retroric came across repositories of a new game that is a sequel to this one. If I can finish it, it will be in a new git repository.

What I mean, is that at some point your game is going to be in game archives, websites, etc... and nobody will know which versions they are playing with. As a developer it is always super annoying when you get people to complain about missing features, bugs, difficulty, length of a game... when they are actually using a 3 years old version and there was 3 updates with additional levels and bug fixes and speed optimization done since.

You are absolutely right. Thanks for the advice. I'll put the game versions in a prominent place. Thanks