Author Topic: MLC 68k (Read 26464 times)

Liazon · « **Reply #30 on:** November 06, 2006, 04:57:00 pm »

don't worry man! progress is progress, and progress in any way, shape, or form is good

most of us are also busy a lot, so don't worry.

bfr · « **Reply #31 on:** November 18, 2006, 08:08:00 am »

I've now implemented integer variables, floating (decimal) variables, and character variables. I'm working on probably one of the most annoying parts - expression parsing. So far, MLC can store an integer constant to an integer variable.

DJ Omnimaga · « **Reply #32 on:** November 18, 2006, 08:27:00 am »

sound amazing, btw how many vars will mlc allow?

bfr · « **Reply #33 on:** November 18, 2006, 10:21:00 am »

5 picture variables, 50 integers, 50 decimal numbers, and 20 strings. There are other variable types, including MLC 2-only variable types, such as pointers, that I don't know how many I will allow yet. I can increase the amont of variables, and even make it unlimited (limited to only the amount of the calculator's memory, but it would be a bit tricky).

DJ Omnimaga · « **Reply #34 on:** November 25, 2006, 07:59:00 am »

aah i see, should be reasonable for arcade type games

Liazon · « **Reply #35 on:** November 25, 2006, 01:06:00 pm »

Pity variables and all that can't be easily implemented dynamically on z80 calcs. Correct me if I'm wrong. I think if the variables could be implemented dynamically, we could have unlimited variables? But then we'd need some kinda of memory checking mechanism to check errors. that'd make it slow wouldn't it? what if the program defines the max memory it will use at any given time and make the calc check if it's available.

I'm just throwing ideas out. So far things look awesome.

bfr · « **Reply #36 on:** November 25, 2006, 01:30:00 pm »

I see what you mean. It probably would be a little slower and would require an error checking mechanism, which would make it even slower. I might just leave it as it is now though unless I encounter some horrible problems or many people start to complain.

bfr · « **Reply #37 on:** December 09, 2006, 06:38:00 am »

I'm rewriting the expression parser because it was horrendously organized before and didn't completely work anyway

. It's going to be done hopefully sometime between this Sunday and the end of Christmas break. I've never really written a mathematical expression parser before, so I don't really know how long it will take.

bfr · « **Reply #38 on:** December 11, 2006, 02:58:00 pm »

I've decided to use a (slightly slower) dynamic variable system, due to weird errors probably due to stack overloading. The dynamic variable system will be better than the current variable system in all ways except for that it will make MLC slightly larger and MLC programs slightly slower. Other than that, the dynamic variables systems means better memory error prevention, better random weird error prevention, and unlimited variables (the only limit is the calculator's memory). I might not be able to finish this any time soon, but I'll hopefully finish the new variable system along with the mathematics expression parser by the end of December.

necro · « **Reply #39 on:** December 11, 2006, 07:34:00 pm »

so, have you implemented sprites yet? Also, how does the C code parse the files?

DJ Omnimaga · « **Reply #40 on:** December 12, 2006, 03:06:00 am »

providing it wont go insanely slow (like BASIC) it should be fine

necro · « **Reply #41 on:** December 12, 2006, 06:31:00 am »

I am wondering because I am still early into learning C

bfr · « **Reply #42 on:** December 12, 2006, 11:46:00 am »

necro: No, sorry, sprites haven't been implemented yet. They'll come after a good variable system and the expression parsers are finished. MLC can't parse the sprite commands' arguments without an expression parser and the sprites' arguments can't be variables without a variable system. I know sprites are an important part of MLC, so I'll try to work on them soon after finishing the new variable system and the expression parsers.

And how does it parser files? Well, don't try this with computer C, but I'm using low-level http://tigcc.ticalc.org/doc/vat.html. I'm using those routines as opposed to http://tigcc.ticalc.org/doc/stdio.html, because it allows for smaller and faster programs. With the higher-level ANSI-compatible routines, one could merely do:

FILE* file = fopen("myfile","w"); // w for write mode

By using routines from vat.h, it's a tiny bit more complicated. Besides, to me at least, it is more fun to use the vat.h routines.

DJ Omnimaga · « **Reply #43 on:** December 13, 2006, 02:46:00 am »

Question: do u think something like this could be done in MLC?

user posted image

Basically this use 4 truncated road pics and two lists (L2 and L3), and depending of if the list element is a turn or coast it display a different road sprite where it's supposed to display. However sprite size keep varying in height, depending of if you are in a coast or not. I was wondering if such program could be done in MLC?

EDIT: that thing is written in BASIC+xLIB btw, don't wonder why it isn't too smooth

Liazon · « **Reply #44 on:** December 13, 2006, 10:19:00 am »

was that your xlibman? cuz that's insanely good!

Author Topic: MLC 68k (Read 26464 times)

Liazon

Liazon

Liazon