Ascii Moon Buggy

[rax]

Hello again,
I had a few free days and decided to test how Oric C language works.
It's wonderful. It is written quite quickly and easily on it. Big Greet (I'm not good at C).

For the experiment, I decided to make a game in ASCII mode similar to this: Moon Buggy https://www.tecmint.com/wp-content/uplo ... -Linux.gif.

It turned out I did not choose the right architecture and I had some problems that I partially decided.

In the beginning, the game worked very slowly, but after I switched several key switches "if" with "switch" and a few functions, the speed increased more than 3 times. It's still slow, I think.

The one problem I could not solve is that when using floating-point numbers, the program starts to work incorrectly. (for example, if I sketch line 44 in obj_gameManager.c).

I also got a "?owerflow error" error several times.

I did not have time for sounds and music that I apologize for.

I'm not particularly happy with the result but ...

Here's the game, enjoy :

[Badger]

I like it.

Personally, I think I would prefer a right to left scrolling, but thats just personal preference.

The gameplay is there.

Badger

[ibisum]

Very nice gameplay! It seems like all thats necessary is a little tweaking with the chars and you'll have made a pretty good game!

Wow, all these new guys with their C programs ..

[coco.oric]

As Ibisum, i found the gameplay nice.
It could be top to add redefined characters and sound (may be somebody can add help rax)

[Dbug]

The one problem I could not solve is that when using floating-point numbers, the program starts to work incorrectly. (for example, if I sketch line 44 in obj_gameManager.c).

Floating point numbers are kind of a hack, basically the compiler has been told on how represent these values as the 5 bytes format used by the Oric BASIC, and then it calls the various floating point routines in the ROM to do the computations, and there are cases where bad things happen, but I was not able to find why.

Also they are very slow, if you need decimals, an easiest way I found was to use 8.8 fixed point arithmetic, it's not as accurate but at least it's fast

[rax]

I thank everyone for the positive feedback ,

My idea was to try the C language, but I played a lot more. I had no idea to do a whole game.

The movement is left because it was in Moon Buggy.

I try the floating point numbers because I wanted to calculate the distance traveled by the formula. I found another way. It was strange why it did not work.

Perhaps the next game will be with sounds and predefined chars.

One question. Who saw the Earth in the game?

While I was creating game, I made and a ascii aquarium. Maybe he should show it too. Nothing special.

p.s. My other nick is "rax".

[Chema]

I had no time to have a look at your game yet, but be sure I will.

In the meantime thanks a lot for contributing to our community!

[ibisum]

EDIT: Hey, you should put this in a repo!

[coco.oric]

Nice fishes Rax.

[rax]

Тhanks ,

I do all this to have fun.
I uploaded all projects in github: https://github.com/raxrax

Regards.

[iss]

Wow! Very cool demos, I like all four! And this clever trick is my favorite:

Code: Select all

sprintf((void *) 0xbb80, "load:%d .... 

[ibisum]

Haha, that sprintf() *is* hilarious, what a fun trick ..

[rax]

Тhanks ,
I tried everything I thought to speed up, but... maybe C is not very suitable for fast games.

[Dbug]

I tried everything I thought to speed up, but... maybe C is not very suitable for fast games.

Well, regarding the speed difference, there are many things that can impact the performance.
From my own tests, I'd say that optimized C (with our compiler) is about 5 to 10 time slower in average than assembler, but when you start to go in things that are pure processing of stuff involving loops and copies, you can easily beat the C compiler by a factor of 50 (because it does not do things like loop unrolling, and uses the zero page very conservatively).

Now, if you want to stick to C, you have to remember a few things:

- Function calls are costly: there's parameter pushing, stack management, etc... typically your one liner functions like void deleteObject(unsigned char objectNumber) or int getpos(unsigned x, unsigned y) would be much faster if they were implemented as macros doing the same thing: The code would be inlined in the function call.

- Avoid having to test for the state of objects to know if they are alive, frozen, dead, etc, it works much better to have objects in lists: The list of objects that are running, the list of objects that can be reused, etc... you get just a single counter, and no need to test for objects[ i].active

- Switch cases are faster than bunch of ifs, but if you only need to test for one specific condition (like in void objectProcessing()) I'm pretty sure that replacing your switch by just "if (objects[ i].active)" would be faster.

- void executeUpdate() is a perfect example of where using lists of objects per type would be much faster than testing for specific object type: Update all your stars in one single batch, then all your meteors, etc...

Generally speaking, this is also true of 6502 assembler: Having lists of stuff to process linearly without doing any check will always be faster than iterating over generic list of items and run specific dispatcher code

[ibisum]

Super fun project, this .. neat to think that there is still more oomph to be weaned from C on Oric ..