This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Seeing as so many of you like C

Seeing as so many of you like C
by on (#222573)
This might be of interest, it seems to be a "lite" C and hence make more optimal code, not tested it my self though https://github.com/RevCurtisP/C02
Re: Seeing as so many of you like C
by on (#222575)
Thanks for pointing that out, it look intriguing. The idea of an almost-but-not-quite-C language makes a lot of sense for the 6502, and the fact that there's a working Atari 2600 example demonstrates how you can mix it with assembly for the critical parts.

I'm not sure it's mature enough that I'd want to use it for anything at this point, but I'm definitely interested in keeping an eye on it.
Re: Seeing as so many of you like C
by on (#222576)
First off, I'd recommend that everyone with a GitHub account add a "thumbs-up" reaction to License (#6), reported by DarkiStar. Once that's resolved, I might have time to try it out.
Re: Seeing as so many of you like C
by on (#222578)
I didn't know about that one, I will keep an eye on it. Thanks!

For now I won't use it right away since my older projects that I'm testing C with are ca65 based so it may not be the right time to try it. Maybe for something new, it may be worth experimenting with it.
Re: Seeing as so many of you like C
by on (#222581)
It's both interesting and disappointing at the same time. Interesting because it's nice to see people attempt stuff like this. Disappointing because it seems extremely limited. Just take a look at this: https://github.com/RevCurtisP/C02/blob/ ... c02vsC.txt It seems kind of like a beefed up assembler.

I'd love to see a language that would have a convenient way to handle 16-bit/24-bit math, and would provide seamless support for SoA (structure of arrays) layouts.
Re: Seeing as so many of you like C
by on (#222582)
That is disappointing.

cc65 would be much faster if the c stack was fixed to 1 page, and the stack pointer was 1 byte.

Then getting a parameter would work like...
ldy sp
lda stack, y

rather than indirect addresses. and 16 bit stack / stack pointer.
Re: Seeing as so many of you like C
by on (#222649)
One thing that this project is definitely missing is #define.

When you have more than 50 different character types in your game and each of them has a huge bunch of fixed properties, then you can easily do this in C:
Code:
#define ALL_CHARACTERS(postfix)\
    Hero##postfix,\
    Monster##postfix,\
    Boss##postfix

etc.

Then you do:
Code:
enum
{
    ALL_CHARACTERS(Type)
};


And for the properties, you can do this:
Code:
#define HeroCanWalkThroughWalls false
#define MonsterCanWalkThroughWalls false
#define BossCanWalkThroughWalls true

const byte CanWalkThorughWallsProperties[] =
{
    ALL_CHARACTERS(CanWalkThroughWalls)
};


Now, I can be sure that something like this:
Code:
if (CanWalkThorughWallsProperties[CurrentCharacter.Type])

will always be correct and that I can later shuffle around the order of the characters in any way I like without having to manually update a bazillion property arrays.
Also, when I add a new character, I simply put it into the macro and let the compiler tell me where it's missing some property names:
Code:
#define ALL_CHARACTERS(postfix)\
    Hero##postfix,\
    Companion##postfix,\
    Monster##postfix,\
    Boss##postfix

-->
Undefined symbol: CompanionCanWalkThroughWalls
Undefined symbol: CompanionMaxEnergy
Undefined symbol: CompanionMetaSprites
etc.

So, I can add these things piece by piece and don't have to search around manually, hoping that I haven't forgotten anything.

dougeff wrote:
That is disappointing.

cc65 would be much faster if the c stack was fixed to 1 page, and the stack pointer was 1 byte.

Then getting a parameter would work like...
ldy sp
lda stack, y

rather than indirect addresses. and 16 bit stack / stack pointer.

I would suggest not to use local variables and parameters at all when using C for an NES project, unless it's not time-critical and you have enough ROM space.
Again a situation where macros come in handy:

Code:
byte DoSomethingParamaterA;
byte DoSomethingParamaterB;

void __fastcall__ DoSomething_(void);

#define DoSomething(a, b)\
do\
{\
    DoSomethingParameterA = a;\
    DoSomethingParameterB = b;\
    DoSomething_();\
}\
while (false)
Re: Seeing as so many of you like C
by on (#222657)
Missing #define is pretty terrible. That said, it would be really easy to replace that functionality with a custom pre-processor written in Python.

That's assuming the core is good enough to be worth making that effort, which I'm not sure is the case here.
Re: Seeing as so many of you like C
by on (#222658)
Can't you just run the source through the C processor first and then compile it?

With GCC it's the -E flag, for example.
Re: Seeing as so many of you like C
by on (#222660)
pubby wrote:
Can't you just run the source through the C processor first and then compile it?

With GCC it's the -E flag, for example.


Yep, good call.