Awesome

Is GCORE fully functional and finished now ?

The fastest line clipping code I saw in action actually took 2 coordinates, like a classical line routine, but then performs some mathematics based on cartesian equations to "keep" the points in the drawing window while not altering the "slope" of the line.

Sorry for the poor explanation, English is not my first language

This page will explain better than me : http://lodev.org/cgtutor/lineclipping.html .

I updated my Axe version from 1.2.1a to 1.2.2 ... now the resulting 15k MirageOS program that uses FullRene doesn't even run properly ... It does run indeed, but all pointers are messed up, and it still crashes on exit (using classic Return, not Return^r).
EDIT : I finally remembered that Axe 1.2.2 moved the A-θ variables buffer to $90D3, which area I used in my program. Oh well.
I had no more success with Return, and using Return^r made MirageOS angry, so I had to use Asm(CDB940) as a return instruction to skip the Fullrene custom exit point ($409B is MirageOS's call _quitToShell). And it finally works

It would be nice if I could simply use Return though.

Epic bump,

It seems that this doesn't work on my TI-83+.fr (2010 edition) under OS 1.19. I have a 15547 bytes program starting with ::.IKARUGAX
:#Axiom(FULLRENE)
:Fcdf()
:ReturnI compiled it for MirageOS, I launched it from RAM (so I had around 8k free RAM when I launched it), it apparently launched properly, and when it was about to exit, it crashed.

Any idea ?

EDIT : it has boot code 1.01 and base code 1.19

The first thing is that MirageOS provides functions to ASM programs, which functions are directly hard-coded in the shell. The second thing is that MirageOS is an app, so all functions address are relative to $4000 IIRC. So if you don't provide MirageOS functions at the correct addresses, just don't run MirageOS programs.

Is it an actual OS already, or is it just code for now ? I mean, do you have a 8xu to test ?

Not me ...

Quote from: Matrefeytontias on November 07, 2013, 07:27:25 am

I don't think that putting user levels right in the compiled game is a good idea. IMO, you should build an on-calc (separate ?) level editor that can generates TNS files that can be loaded by the main game. This is easy enough, since you just have to generate files that follow the same scheme than your hard-coded levels.

One day I'll get around to something like that, but I have almost no clue how to do that. For now, I think this way might be acceptable just to get the program off the ground before going crazy about it, but that does sound like an interesting concept!

Maybe someone could help me with that!

I sure can it doesn't rely on any particular language, it's just a theory that you can put in practice as you want. But I do program for Ndless in C anyway.

edit: as of now, I don't know any on calc c-compilers, so the possibility of this I think might be almost zero . Someone, quick, prove me otherwise!

You don't need any on-calc C compiler to generate the files I talked about, but only a fopen() function. The content of such file is up to you.

What I meant is that you could build a mini-scripting system. To do that, you must know what the content of the file refers to. For example, you know that if you encounter a 0x80 in the level file, it means that you put an obstacle at a certain position. And you carry on parsing the file as the player advances in the level. You see what I mean ?