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

Limitiation or compromise if write program in c

Limitiation or compromise if write program in c
by on (#211040)
First, happy new year from Japan!

One of my new year resolution is to try to write something for the nes, anything is fine as long as I finish it. Since I didn't touch asm code for a while, it would take some time before getting back on track. My best guess would be to write code in C but I'm not sure what are the compromise you have to do if you decide to go that way.

I know that a few homebrew were made in C so I would like to know what are the compromise or gotcha that you have to be aware if you write most of the code in c.
Re: Limitiation or compromise if write program in c
by on (#211041)
Performance and size. Grab cc65 and neslib, and off to coding!
Re: Limitiation or compromise if write program in c
by on (#211045)
Passing arguments to functions is incredibly slow for the 6502. Pass 1 argument at max, it can use the a and x registers for the first argument.

I recommend the neslib. Use globals, basically everywhere.

The main advantage of C is ease in programming. I even find debugging easier in C.
Re: Limitiation or compromise if write program in c
by on (#211051)
There are a few useful hints on this site, especially the point "Optimization":
https://shiru.untergrund.net/articles/p ... s_in_c.htm

dougeff wrote:
Passing arguments to functions is incredibly slow for the 6502. Pass 1 argument at max, it can use the a and x registers for the first argument.

If the function is implemented in C, has one parameter and is declared __fastcall__, the compiler will still put the variable into the software stack first. So, functions written in C should not use parameters at all.
If the function is implemented in Assembly, then one parameter is alright. If you declare the function as __fastcall__ (which you should do with any function anyway since there's no disadvantage in doing so), it will be put into A (or, if it's two bytes wide, into A and X) and your Assembly function can decide for itself what it wants to do with it.


Besides, even with global variables, you can still simulate normal function calls with the help of macros:
Code:
extern unsigned char DoSomething_Parameter1_;
extern unsigned char DoSomething_Parameter2_;
extern unsigned char DoSomething_Parameter3_;

void __fastcall__ DoSomething_(void);

#define DoSomething(parameter1, parameter2, parameter3)\
{\
    DoSomething_Parameter1_ = parameter1;\
    DoSomething_Parameter2_ = parameter2;\
    DoSomething_Parameter3_ = parameter3;\
    DoSomething_();\
}


If you program efficiently, then C should not prevent you from writing real games.

I wrote a jump'n'run in C:
http://www.youtube.com/watch?v=Eee0yurkIW4

This game has platforms, jump physics etc., so the movement functions are a bit more complex than a simple "if button up, then check for wall at position (X, Y - 1)". And still, it works completely without lags.

Some stuff should still be written in Assembly, like general functions (CopyArray*, randomizer etc.), the stuff that happens in NMI or the sprite rendering function (the one that turns the meta sprites into hardware sprites).
But apart from that, I managed to program the whole game logic in standard C and there was never a situation where I had to optimize a random part of the game to be written in Assembly.


* CopyArray, FillArray etc. should be reimplemented because the official C functions memcpy and memset use a size parameter of two bytes (type size_t). This makes those functions bigger and more complex than if you simply use a byte value as the size parameter.
After all, when do you ever need to copy or fill more than 255 bytes to an array at once?
Also, they use local parameters.

Instead, your own CopyArray could look like this:

Code:
In C:

void __fastcall__ CopyArray_(unsigned char size);

#define CopyArray(destinationArray, sourceArray, size)\
{\
   CommonPointer1 = destinationArray;\
   CommonPointer2 = sourceArray;\
   CopyArray_(size);\
}

In Assembly:

_CopyArray_:

   TAY

@loop:

   CPY #0
   BEQ @end

   DEY

   LDA (CommonPointer2), Y
   STA (CommonPointer1), Y

   JMP @loop

@end:

   RTS


Do you already know what kind of game you want to program?

dougeff wrote:
I even find debugging easier in C.

How do you debug the C code of an NES game?
Re: Limitiation or compromise if write program in c
by on (#211053)
Performances and the uses of parameters in c was mostly what I though would be an issue so it seems my guess were right or I did remember some of the comments posted on nesdev in the past.

thank you for refreshing my memory on the subject!

I'm not expecting to write everything in C since my experience from the dos days reminds me that some part has to be written in assembler because of performance issues (any copy related method mentioned above are better in asm).

DRW wrote:
Do you already know what kind of game you want to program?


Right now I have not decided yet. I always had ideas that were too technical so they went nowhere so I need to focus on something small first so I can build some base code.

There is one game I started 25 years ago under dos that I would like to make on the nes but this game too is incomplete so only the basic characters and concept would be ported. It was a double dragon style game and liked that alot in the past but now my taste changed a little bit but still would like to see something out of it.

I should start with a one screen game, it just that I never really liked those in the first place. Still, it would be a good start.

Is using other modules like either famitracker or famitone(?) more complicated with c code?
Re: Limitiation or compromise if write program in c
by on (#211054)
Banshaku wrote:
I'm not expecting to write everything in C since my experience from the dos days reminds me that some part has to be written in assembler because of performance issues (any copy related method mentioned above are better in asm).

I was surprised in the end that I only had to use generic functions in Assembly. There was never an issue where I had to write a real game-specific function (like MoveHero etc.) in Assembly.

Banshaku wrote:
It was a double dragon style game and liked that alot in the past but now my taste changed a little bit but still would like to see something out of it.

My hint: Beat'em ups are always pretty boring due to their slow speed: You have to hit your opponents many times and the game prevents you from going on until all of them are defeated.
How about a fast-paced beat'em up?

Banshaku wrote:
I should start with a one screen game, it just that I never really liked those in the first place. Still, it would be a good start.

I was pretty glad that my first game was not just a one screen game, but that I actually included full scrolling and realtime level loading. This way it was a mundane issue to do this for the next game.

Banshaku wrote:
Is using other modules like either famitracker or famitone(?) more complicated with c code?

No. Just like you can mix and match C code with Assembly, you can also include the Assembly code of FamiTone into your own code.
You might want to create a little Assembly file that wraps the other file.


Besides, the FamiTracker driver itself should probably not be used. The code is very big (about 5 KB), the music files will become big, it doesn't have support for sound effects and I assume it's not very efficient and you need the CPU time for other things.

If FamiTone is not too limited for your music compositions, it's pretty good for games.
Re: Limitiation or compromise if write program in c
by on (#211059)
I have an idea for a multiple player game, more or less a beat-em-up, but I need to define what the characters can do and do quick prototype to see how interesting it would be. Maybe this would be the chance to build it in C and test how it goes.

As for Famitone, I'm not a very talented artist music wise so I do not use much effects so I guess I would have no issue with the famitone requirements. I was using up to now FT 2.7 driver (which is smaller) but the issue was sound effects.

When I have something working I will be more than happy to share it. For now, it's just a new year resolution. The other reason for C is to be able to port it to other platform but maybe with the nes limitation (for c code) it may just be wishful thinking only.
Re: Limitiation or compromise if write program in c
by on (#211063)
I have ported NES games written in C to Genesis and GBA without much issue.
Re: Limitiation or compromise if write program in c
by on (#211065)
Banshaku wrote:
I have an idea for a multiple player game, more or less a beat-em-up, but I need to define what the characters can do and do quick prototype to see how interesting it would be.

How about a first attempt of a real "Street Fighter II"-like fighting game instead of a multiplayer versus version of "Double Dragon"? Maybe with small 16 x 40 characters in the first step. (Huge characters with many animation frames would require MMC3 for instant change of the CHR values.)

Banshaku wrote:
The other reason for C is to be able to port it to other platform but maybe with the nes limitation (for c code) it may just be wishful thinking only.

The limitations for C code (like using global variables instead of parameters) are nothing that go against standard C, so you can use the code for everything else as well. It might be considered bad programming style in another context, but it's still all valid C.

What might be a problem when it comes to porting: There's probably less abstraction in NES games.

For example, my characters on screen contain a pointer variable to a meta sprite that is the currently drawn animation frame. And the data that the pointer points to is an array of tile values from the CHR ROM.
So, I don't have abstraction values for PlayerStanding, PlayerWalking1, PlayerWalking2, PlayerWalking3 etc. Instead, it points directly into the data itself and the UpdateSprites function uses the pointer for buildup.

On another platform, your meta sprites definitions would probably not consist of a bunch of tile values, but each animation would maybe be a bitmap file. (And if you write clean code, your value in the game logic would just be an index for a lookup array, specifically so that you can switch the underlying data without having to change the game logic code. But for the NES, this abstraction layer would cost ROM space and CPU time.)

So, you would have to redefine the pointer to an array of byte values into a string variable that hold the bitmap file name. Or an integer that holds the Windows bitmap resource ID. (Or an integer that holds the index to an array of implementation-defined data.)

Same with the background buildup:

When it's time to update the background, the game logic fills an array with data that's very close to how the PPU structures its data, so that the NMI can process the array as fast as possible.
You probably don't have the same tile-by-tile-with-values-from-CHR buildup in a PC game unless you actually recreate the behavior of the NES PPU. So, you would have to rewrite these parts and they might be mixed with your regular game logic code.
Re: Limitiation or compromise if write program in c
by on (#211068)
DRW wrote:
My hint: Beat'em ups are always pretty boring due to their slow speed: You have to hit your opponents many times and the game prevents you from going on until all of them are defeated.

I'd bet a lot of the scroll stop behavior in these games derives from CHR address space and palette limits, with two players and two enemy types allowed to be loaded at once. The other option is pop-in, where enemies just blink into existence once all enemies of a particular type are defeated.

DRW wrote:
How about a fast-paced beat'em up?

Once it gets fast enough, it stops feeling like a beat-em-up in favor of another genre entirely. I never thought of Haunted: Halloween '85 as any more of a beat-em-up than, say, Super Mario 64.
Re: Limitiation or compromise if write program in c
by on (#211071)
DRW wrote:
[
How about a first attempt of a real "Street Fighter II"-like fighting game instead of a multiplayer versus version of "Double Dragon"? Maybe with small 16 x 40 characters in the first step. (Huge characters with many animation frames would require MMC3 for instant change of the CHR values.)


What I had in mind was not a double dragon like fighting game but more a fast paced arena like fighting with traps, wall jumping, maybe weapons (or some characters have weapon) either one or one or one to many (depending of limit with four score). The concept is raw and to make it interesting, you have to build interesting battle ground that allow strategy to attack the other player.

The idea is still raw but this is maybe an idea that came out from a screenshot I saw from another game (never saw the game play though) and though it could be interesting on the nes, if the game play is fast enough. This means small characters and interaction with the environment.

As for porting, it was more for other platform like sms, pce etc. The logic may be portable (to some degree) but to abstract the hardware may not be possible so I guess most code must be adapted for the platform anyway.

Once I have some concept I will try to share it. For now I didn't but anything on paper yet. What is the most important is the battleground and make interesting fighters that are balanced.
Re: Limitiation or compromise if write program in c
by on (#211073)
Quote:
How do you debug the C code of an NES game?


Let's say you want to do something like this...

If (some_flag && (x_position>25) && (direction == left)) {
do_something();
}

this is much easier to understand than the equivalent asm, which would be about 10-15 lines long. And, I have it compile and add the C source to the asm file. If, there's a problem, I can set a breakpoint, and step through the code, and look at the asm file (with C source), and still know what's going on.

cc65 command line directive --add-source

even coming back to this code a year later, it would only take an instant to comprehend it.
Re: Limitiation or compromise if write program in c
by on (#211076)
Banshaku wrote:
As for porting, it was more for other platform like sms, pce etc. The logic may be portable (to some degree) but to abstract the hardware may not be possible

I'm not entirely sure to what extent the logic would be efficiently portable.

Z80, MC68000, and MIPS have indexing modes with a large (16- to 32-bit) pointer and a small (at least 7-bit) constant offset. This leads to a preference for an "array of structures" (AOS) organization of data, where all fields related to one object are consecutive in memory. For example, the X and Y coordinates of an object might be at $F000 and $F002, while the X coordinates of two different objects might be at $F000 and $F020. In C, it'd look like this:
Code:
#define NUM_ACTORS 16
struct Actor {
  uint16_t x, y;   // displacement
  int16_t dx, dy;  // velocity
  uint8_t health, actor_type, frame_timeleft, frame;
  // et cetera
};
struct Actor actors[NUM_ACTORS];

Then a program can keep a pointer to the current actor structure, which C++ calls this, in a machine register and access fields using each field's offset. In Z80 (not 8080/8085 or LR35902), this is IX; in 68000, this may be A0; and in MIPS, this is the first argument register ($4 aka $a0). Indexing is a bit trickier on 8080/8085 and LR35902: a pattern shown in this post is to pad each struct to a power of two bytes and aligning it to its "natural" boundary so that you can access fields of the object pointed to by HL by doing math on the lower bits of L, leaving H and the upper bits of L alone. I wonder what practical C compilers for 8080/8085/LR35902 do, or what Z80 C compilers do if IX and IY are already occupied.

The fast indexing modes in the 6502, by contrast, add a small (8-bit) variable offset to a large (16-bit) constant pointer. This leads to a "structure of arrays" (SOA) organization, which places values of one field of several objects in consecutive addresses. So you'd get X and Y coordinates of an actor at $F010 and $F030, but X coordinates of multiple actors at $F010, $F011, $F012, ...
Code:
#define NUM_ACTORS 16
uint8_t actor_xsub[NUM_ACTORS];
uint8_t actor_x[NUM_ACTORS];
uint8_t actor_ysub[NUM_ACTORS];
uint8_t actor_y[NUM_ACTORS];
uint8_t actor_dxsub[NUM_ACTORS];
int8_t actor_dx[NUM_ACTORS];
uint8_t actor_dysub[NUM_ACTORS];
int8_t actor_dy[NUM_ACTORS];
uint8_t actor_health[NUM_ACTORS];
uint8_t actor_type[NUM_ACTORS];
uint8_t actor_frame_timeleft[NUM_ACTORS];
uint8_t actor_frame[NUM_ACTORS];

C is traditionally used on machines with large pointer+small offset, which prefer an array of structures. I'm not aware of any C implementation (or even any high-level language in the first place) that automatically translates code to the structure-of-arrays approach. Is there a good way to use the C preprocessor to output both structure-of-arrays and array-of-structures code from one source file?
Re: Limitiation or compromise if write program in c
by on (#211079)
A little stylistic suggestion: I would still put these values into a struct:

Code:
/* In a .h file: */

#define NUM_ACTORS 16

struct Actors
{
    uint8_t xsub[NUM_ACTORS];
    uint8_t x[NUM_ACTORS];
    uint8_t ysub[NUM_ACTORS];
    uint8_t y[NUM_ACTORS];
    uint8_t dxsub[NUM_ACTORS];
    int8_t dx[NUM_ACTORS];
    uint8_t dysub[NUM_ACTORS];
    int8_t dy[NUM_ACTORS];
    uint8_t health[NUM_ACTORS];
    uint8_t type[NUM_ACTORS];
    uint8_t frame_timeleft[NUM_ACTORS];
    uint8_t frame[NUM_ACTORS];
};

extern struct Actors actors;

/* In a .c file: */

struct Actors actors;

This way, you don't need to declare every single variable in a C file and the same set of variables as extern in a header file.

(Also, I like to typedef unsigned char to byte and signed char to sbyte.)
Re: Limitiation or compromise if write program in c
by on (#211087)
Banshaku wrote:
What I had in mind was not a double dragon like fighting game but more a fast paced arena like fighting with traps, wall jumping, maybe weapons (or some characters have weapon) either one or one or one to many (depending of limit with four score).

Something like "Nekketsu Kakutou Densetsu"?
Re: Limitiation or compromise if write program in c
by on (#211090)
dougeff wrote:
Passing arguments to functions is incredibly slow for the 6502.

In what way did you have in mind? I cover parameter-passing via stacks in chapter 6 of the 6502 stacks treatise. The efficiency shows through more in the listings for recursive functions in chapter 15.
Re: Limitiation or compromise if write program in c
by on (#211091)
Unfortunately, we're talking about the default cc65 software stack.

Everything that's not explicitly global, static, or {local and compiled with --static-locals} gets put on the stack, and when every single variable involves stack manipulation it's an awful lot of added computational overhead.
Re: Limitiation or compromise if write program in c
by on (#211092)
Got it.
Re: Limitiation or compromise if write program in c
by on (#211119)
If you really need functions with parameters so your code is less of a mess, and you can afford a bit of overhead, have a set of multi-purpose global variables (and be careful ;) ) and copy the parameters to the globals at the beginning of your function.

Anyways, I have a set of multi-purpose global variables and 75% of the "strange bugs" I spend hours fetching have to do with it :lol: :lol: :lol: :lol:
Re: Limitiation or compromise if write program in c
by on (#211134)
DRW wrote:
Something like "Nekketsu Kakutou Densetsu"?


I like Kunio games but this was not what I had in mind. I want the game to be fast, no dept in the screen so you have to move from platform to platform very fast and attack the other player(s).

I did a quick search to try to find back the screenshot that inspired the idea and I think it was the game Towerfall on the ouya. I only saw a screenshot of (maybe) that game and I like the limited scope of the screen but I'm not sure if this is exactly what I had in mind since I never saw the gameplay so it may be similar.

I want to create characters with different skill set (strengths, speed, range, size etc) that can battle in a limited stage. Some passage would allow you to go from top to bottom (or left to right depending of the stage selected), there would be traps, part that help you move faster etc. You can kick-jump on wall to go higher, use the environment to move or attack, etc. That could be a good small project to create a code base for bigger projects.

Now that there is a windows version of towerfall (didn't know about that) I may give it a try and look at some of the video online and check if this is what I had in mind or not.

na_th_an wrote:
Anyways, I have a set of multi-purpose global variables and 75% of the "strange bugs" I spend hours fetching have to do with it :lol: :lol: :lol: :lol:


I remember that trying parameters that way in assembler too many bugs came out because of that. I guess I will to figure out the balance of usability and how buggy it may become because of such feature.
Re: Limitiation or compromise if write program in c
by on (#211138)
na_th_an wrote:
Anyways, I have a set of multi-purpose global variables and 75% of the "strange bugs" I spend hours fetching have to do with it :lol: :lol: :lol: :lol:

Here's a hint: Mark the function name with the highest number of variable that is used.

If you use var1, var2 and var3 in the function, call your function MyFunction_var3.
This way, any function that calls MyFunction_var3 knows that it shouldn't use var1, var2 and var3 if it wants those values to remain consistent before and after the function call.

Of course, this also counts for outer functions. If MyOtherFunction doesn't use any variables itself, but calls MyFunction_var3, then of course you have to rename it MyOtherFunction_var3 so that any code that calls this function knows that var1, var2 and var3 are used somewhere inside.
Re: Limitiation or compromise if write program in c
by on (#211139)
@Banshaku:

O.k., so in this case, you first have to write a general platformer engine and then a way for the characters to attack each other.

Advantage: You can use the same basic engine to program a platform fighting game and also a common sidescroller jump'n'run.
Re: Limitiation or compromise if write program in c
by on (#211156)
DRW wrote:
na_th_an wrote:
Anyways, I have a set of multi-purpose global variables and 75% of the "strange bugs" I spend hours fetching have to do with it :lol: :lol: :lol: :lol:

Here's a hint: Mark the function name with the highest number of variable that is used.

If you use var1, var2 and var3 in the function, call your function MyFunction_var3.
This way, any function that calls MyFunction_var3 knows that it shouldn't use var1, var2 and var3 if it wants those values to remain consistent before and after the function call.

Of course, this also counts for outer functions. If MyOtherFunction doesn't use any variables itself, but calls MyFunction_var3, then of course you have to rename it MyOtherFunction_var3 so that any code that calls this function knows that var1, var2 and var3 are used somewhere inside.


Now that's a great idea, thanks. I'll try and come up with a nomenclature for my next project.
Re: Limitiation or compromise if write program in c
by on (#211162)
dougeff wrote:
Quote:
How do you debug the C code of an NES game?

cc65 command line directive --add-source


I built a tool on top of this, called annotatecc65, that adds the original C source into FCEUX's debugger, which makes debugging very straight-forward. I'm interested if anyone has tried it out and found it useful.

https://github.com/dustmop/annotatecc65
Re: Limitiation or compromise if write program in c
by on (#211163)
How come I didn't know this? This will come extremely handy, thanks!
Re: Limitiation or compromise if write program in c
by on (#211200)
na_th_an wrote:
This will come extremely handy, thanks!


Cool! Welcome! If you have any questions or issues please feel free to DM me or file a github issue.
Re: Limitiation or compromise if write program in c
by on (#211202)
nice!
Re: Limitiation or compromise if write program in c
by on (#211204)
All I have to say is that I used it today and it was bliss. Great job!
Re: Limitiation or compromise if write program in c
by on (#211613)
I made an earnest attempt over a 3 month period to adapt to C in early 2016 or so, for my current project. While I can imagine smarter folks benefiting from it, I just couldn't get used to it. I had too many weird problems I didn't know how to solve. Either something with syntax, or I didn't understand whether something allocated ram or rom, or I just had to bastardize the C language so horribly and mangle it beyond comprehension I might as well be coding in asm anyway. And finally, I attempted to write a metasprite routine in C, and drawing a large 18 sprite metasprite took a frame and a half. Rewriting the same routine in assembly and drawing the same large sprite took about 1/10th of a frame. Obviously nobody would write a metasprite routine in C to begin with, but that difference in speed was so alarming I became afraid that I would run into performance issues way more often than I'd like if I adopted C. I'm also terrible at reading code and if there's ever a problem, I really didn't want to pore over the code cc65 generates...OH! And things like sub pixel precision, like 8.8 velocities added on 8.8.8 coordinates? That comes out so naturally in asm. The pointer math or other workarounds one must do in C are rather unpleasant.

The bottom line for me though is the "feeling" of coding in assembly just makes me happier, period. Totally irrational, perhaps, but that's a good enough reason for a hobby where nothing matters but whether one is happy anyway.

Use what you like, not trying to discourage anyone from using C, I think it's really awesome it's being used so well by many excellent fellow homebrew devs.
Re: Limitiation or compromise if write program in c
by on (#211615)
GradualGames, I had those problems and a lot more. I have partly come to the opinion that even for intelligent people, which programming language approach works best for a person depends partly on what kind of brain they're born with. For me, Forth was a natural. My enjoyment of assembly has also increased in recent years as I have done more to raise the level of the language, using macros to make nestable program structures. I really cannot understand how anyone could go for C.
Re: Limitiation or compromise if write program in c
by on (#211619)
GradualGames wrote:
While I can imagine smarter folks benefiting from it, I just couldn't get used to it.

It doesn't really have to do with being smarter. In fact, I would actually prefer to be able to write code fluently in Assembly because it gives you control over every single byte that ends up in the ROM.

But while I can read and write code in Assembly, it takes much, much longer for me than it does in C.

I could never write a whole game in Assembly, but I've been programming in C-like languages for 14-15 years, so writing a game for the NES in C is easily doable for me.
Re: Limitiation or compromise if write program in c
by on (#211623)
I think it has to do with your background. I've been coding games in C since I can remember. Before trying the NES, I had already completed games for several retro platforms... in C. So it feels natural. When you are my age and you have my (lack of) spare time, it's hard to empty your glass and start anew. In my case, besides - I'm not a very constant person. I have new ideas faster than I can make them real, so I just need results, even if they are not optimal.

So, long story short: I prefer C mainly because I can get results from it *now* and *fast*. And I'm pleased with such results.

Besides, it's entertaining to fight the compiler and try to get the most of it.
Re: Limitiation or compromise if write program in c
by on (#211625)
The ironic thing is I actually did make some small games in C for DOS years ago, then I was employed doing C/C++ for several years. So I apparently know the language well enough to have a job doing it, but on NES I just couldn't get used to it. I think I ran into at least one situation that I really had no idea about. Like, something in the cc65 compiler was stepping on variables I was allocating in my sound engine or something like that, and I couldn't figure out why. There's just so much noise like this to worry about. Doing C on a PC you rarely have to think about the actual linker configuration, on the NES it appears necessary to understand these things really well. Which I do, in pure asm. With cc65, it's like I suddenly have to understand the compiler itself in order to use it effectively. That's how it felt to me, irrationally, in any event.

I think the key phrase there na_th_an is that you like to fight the compiler to get the most out of it; I found this act too frustrating; I'd rather just write the asm code. By the time I was done wrestling with the C compiler I would have written the asm anyway, haha! :lol:

*Edit* I'll have to say though to answer the OP: I keep seeing amazing homebrews made in C. I don't think it would be a compromise, especially since you already know asm and can use it to get over performance issues. It really boils down to whether you're interested in the language and enjoy working with it on NES. So I'd say give it a try for a few months like I did and you'll quickly find out whether you like it or not.
Re: Limitiation or compromise if write program in c
by on (#211632)
@GradualGames

I guess the main reason I'm investigating if I should try in C or not is it has been sooo long that I didn't touch asm code that either of them will feel "unnatural" in the beginning anyway :lol: but in some of the game logic could be used in other scenario (for very basic games) then it could be interesting in C. I will try it soon.

An example of very good homebrew that came out 10 days ago and done in C but on another platform (sms) is Silver Valley. For such a long game I was quite impress by the result. Not to say that there was no good C homebrew on the nes (na_th_an and DRW have shown that is quite possible to do so).

Can't wait to touch some code after all those years.
Re: Limitiation or compromise if write program in c
by on (#211634)
Garth wrote:
GradualGames, I had those problems and a lot more. I have partly come to the opinion that even for intelligent people, which programming language approach works best for a person depends partly on what kind of brain they're born with. For me, Forth was a natural. My enjoyment of assembly has also increased in recent years as I have done more to raise the level of the language, using macros to make nestable program structures. I really cannot understand how anyone could go for C.

Cool site. I've been building up my own set of macros to help, haven't taken it this far yet though. Maybe it has to do with one's comfort level with relinquishing or delegating control to something else. With assembly and macros, you maintain control. I like it this way.