Seeing as so many of you like C
Moderator: Moderators
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Seeing as so many of you like C
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
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.
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.
My games: http://www.bitethechili.com
Re: Seeing as so many of you like C
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
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.
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
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.
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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: Seeing as so many of you like C
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.
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.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Seeing as so many of you like C
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:
etc.
Then you do:
And for the properties, you can do this:
Now, I can be sure that something like this:
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:
-->
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.
Again a situation where macros come in handy:
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: Select all
#define ALL_CHARACTERS(postfix)\
Hero##postfix,\
Monster##postfix,\
Boss##postfix
Then you do:
Code: Select all
enum
{
ALL_CHARACTERS(Type)
};
Code: Select all
#define HeroCanWalkThroughWalls false
#define MonsterCanWalkThroughWalls false
#define BossCanWalkThroughWalls true
const byte CanWalkThorughWallsProperties[] =
{
ALL_CHARACTERS(CanWalkThroughWalls)
};
Code: Select all
if (CanWalkThorughWallsProperties[CurrentCharacter.Type])
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: Select all
#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.
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.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.
Again a situation where macros come in handy:
Code: Select all
byte DoSomethingParamaterA;
byte DoSomethingParamaterB;
void __fastcall__ DoSomething_(void);
#define DoSomething(a, b)\
do\
{\
DoSomethingParameterA = a;\
DoSomethingParameterB = b;\
DoSomething_();\
}\
while (false)
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Seeing as so many of you like C
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.
That's assuming the core is good enough to be worth making that effort, which I'm not sure is the case here.
My games: http://www.bitethechili.com
Re: Seeing as so many of you like C
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.
With GCC it's the -E flag, for example.
Re: Seeing as so many of you like C
Yep, good call.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.
My games: http://www.bitethechili.com