hi there !
I am a new bee here but working fast and learning too.
My son, Thomas, loves ORIC. I don't know why, perhaps because I do !
During 2017 holidays, we did a little game : EDGE for ORIC ( a simplified clone of a similar game for mobile phones)
It was an opportunity for me to deal with sprites, masks, hires, isometric 3D, bit level, and so on.
and an opportunity for him to show me his graphics talents.

I give you this in attachment. (B is a modified version with different key bindings)

It's my second game on an ORIC, and my second game at all during my whole life ! first was 2048...
so, be kind with us !

Now I would like to do 3 or 4 things :
- reduce code size (I am using OSDK: ASM and C. I saw C generated code : there is a lot of garbage like /STA n LDA n STA n/... ) --> I can do it
- include some music using IRQ : I don't know how to do that
- learn more about sprites and masks as I can see mine are not optimized... If I wanted to generate all possible sprites needed for this little game, I wouldn't have enough memory for levels...
- include the possibility to load new levels from a disk or a tape
- make a LEVEL EDITOR --> I can do it, but perhaps won't have the time for it

If anybody interested, please leave a message, and I'll give you the sources and all explanations needed
thanks !!!
Dr Psy

Hi and congrats! Your game looks really very nice and interesting. I like especially the rotating-jump move .
I found small glich - color attributes are not cleared on the right of the 'EDGE' logo.
To reproduce: cload Edge.tap, on first level press 'i', press 'u' ... you'll see it.
About size optimization at first place: $63C2..$8302 - 8000 bytes containing $40 do you need them statically allocated?
You can use compressed splash picture. Lot of bytes can be squeezed from strings - there are lot of spaces - '$20' probably for text alignment. Another thing is the size optimization of C code - I can recommend to try CC65 tool chain too - just to see the difference.
But it depends and it's worth only if you have more complex C code (for instance when the game logic is written in C).
Else the game definitely deserves some sound/music - MYM player.
Special greets to Thomas for helping to lower the average age of the Oric fan community!

Thanks for your compliments !
I also like the little animation of the cube, which seems to give life to this little thing. idea and sprite look and feel and design are from Thomas.

The problem of color attribute of the Edge Logo is fixed in the new version.

The ideas behind this little program are a mix of "generic modules" and specialized ones. In particular, initially, I wanted to create a very simply to use module for sprites. That's what I did, but when I dealt with masking parts of the sprite in the 3D playing field, I introduced some special code into it... So it's not optimized, but it's easy to maintain I think.

About size : I use 2 caches of the size of the screen to generate the background and then to move the sprite of the cube on it, including 3D masking effect. I have no solution in mind to change that... Except to reduce the size of this space to the strict bytes necessary for the 8x8x8 playing field.

all caches and different memory spaces are aligned to 256 bytes pages. This generate empty and unused memory blocks... I thought I had to reduce the number of instructions in loops because the playing field represents 512 tiles max. Actually more than 200 in many cases. And I wanted to obtain a good "speed feeling" when using it.

I'll try to look at CC65. I never used this compiler.
What I did was to rewrite some parts of the C main in assembler, in particular all multiplications. And I could regain hundreds of bytes this way.

And thank you for the link to MYM ! I'll have a look at it.

I don't know how to make some good noises when crashing, jumping, etc. Any Idea ?

ISS already answered some of the questions, but generally speaking:
- Neither CC65 or the OSDK compiler will give you small and compact code. CC65 is less worse, but we are talking incremental improvements. Think of C as a nice way to prototype, but ultimately assembler is the way to go.
- If you really want to make the program smaller, it's totally possible to compress the executable, that will shrunk it down nicely.
- For the music and sounds, it's a bit complicated, it mostly depend of how much CPU time you have and if you really want to stay on tape.

If you want to push your game to another level, ideally you should move to disk based format, that would allow you to have a lot more room, use samples for the game audio, have multiple musics, etc...

Regarding the game itself, should definitely have a menu to choose the keys, IL/UH is not super practical

For the visual, you could also try to play with alternate colors on odd and even lines, that would allow you to have the background and the sprite using different colors, not sure how good that would look, but probably worth trying

Regarding the source code, you can get a SVN account if you want, so we could add the project to the defence-force repository along the other games.

This is a very nice game! Its reminiscent of marble madness, in a way .. which is to say, what about adding the element of enemies to it at some point?!

(I would definitely have bought this game and put it in my favourite-tapes box when I was a kid.)

I dunno about music though - wouldn't some kind of sound effects be more useful? I imagine moments when the sound might be of use in the gameplay, like if you land next to a tile that has 3 sides, it gives you little cues about the walls around you on each tile, and so on ..

Anyway, back to playing it! Very well done - and might I say, an inspiration for me and my kids to get it together and make a nice game together.

Thanks for your congrats !
I can post the code in SVN repository as you propose.
It's not optimized as my first aim was to produce it before the end of the holidays : it was done in only 20 days, and not spending all my time on it, so...

Thanks for your ideas !
Now, I need time to implement them (holidays ended for me) !

I dunno about music though - wouldn't some kind of sound effects be more useful? I imagine moments when the sound might be of use in the gameplay, like if you land next to a tile that has 3 sides, it gives you little cues about the walls around you on each tile, and so on ..

Couldn't agree more.
Music in puzzle game can end up being a bit boring, while sounds can make a real difference!
But on the programming/discovery side, it's certainly not as challenging as a music could be