84 replies to this topic

[huhn_m]

Your right burntfuse! The latest version is still on the <{GNULINUX}> of my Notebook ... I copy it right now and will update the doc then.

For the CLSN:

I would do it this way:

Limit the Numbe of boxes to 256 (good for numbering)
For the "Same name" boxes I would really much like to create some kind of grouped version (read sth. about it somewhere).
So say you call the box "Group:Name" and then you can check for collision with "Group:Name" or wirh "Group:*" which would include all boxes of the group ("*.*" is forbidden because of speed) Also I would limit the objects in one group to 8).

Objects that dont need grouing (like the one box character) will get in a "general group" which will have no name ":foe01" for example. The unnamed group will accept 64 boxes.

This is my idea for the usage in the data section:

Group:Name ---> 0:0 (first group, first name)
In the memory area for the CLSN boxes you will have 1 byte for the group (0 beeing the unnamed group) and 1 byte for the id. This byte (5 bits remaining) does also include:

*a collide flag that will call the COLLIDE function with the names of the 2 objects if set and if a collision happens (good for constantly moving objects)

*a rotate flag (need to be set if the box needs to be rotated too (good for speed if you have a sprite where the box needn't be rotated). The box is only rotated if on

*a flip flag (same as above for flipping)

2 preserved flags

then the 4 edges folow (? 1 byte) --> 4 byte and then you have 6 bytes per box.

this makes for the unnamed group a maximum of 600 bytes
and for the other groups (255*8*6) = 11,96 KB maximum

...

thinking about it I also come slowly to the conclusion that a data section has some major benefits for speed on such complex solutions that actually are not set up but only changed during runtime ... maybe I'll reintroduce it. .. so till I decided this and worked it out no beta

Anyway

I need urgently a good 5x6 font (5 pixles + 1 free col for space and 6 pixels + 1 free line) If anyone is skilled at making one (paint) then PLEASE do so. I simply can't do a good font ... I had one for CNC but it looked ugly. I can upload it if you want but I don't think I'll use it for MLC2 ...


here is the new MLC2 verision: www.earthforge.com/huhnm/MLC/MLC21012.pdf

(I also updated the link in the first post)

[Deimos]

Great idea with the box-based CLSN, it will be perfect here, as it's flexible and it's up to programmer to decide if he wants more precission or more speed.

For the font, does it HAVE to be a 5x6 one? maybe you could consider using 4x7 MLC1 font?
Anyway, i'll try to create some font but i don't promise it will be great


EDIT:

Ok, here's something i made in those 10 minutes: (5 pixels per character + 1 pixel blank space. Is that what you meant?) I just didn't have any good idea for '{' and '}' characters...

[Marco]

Hi,

maybe I could help a bit with the font. For another project I made a modified ASCII char table including most greek chars and special math / logic symbols once. Maybe you could need some parts of it, the one is 5x6, 5x7 the other:

[huhn_m]

I think I'll use marcos font ... it seems quite nice and complete.

thanks for your work though, deimos but there are some chars missing.

I'd like 5x6 since this gives us 10 lines of text (like marco did it) and 21 columns (like the original font for the casio).

I can't imagine that 4x7 is readable since the chars are quite narrow then and chars like y or w or m look difficult.
You can't see wether it is m or n anymore then.

[huhn_m]

there is an error in the second line of characters. It is 7 chars high ...I fixed it but wanted to let you know in case you run into errors.

[SRM]

About CLSN, I don't really get what you mean about group and name. Will boxes be associated to bitmaps or not ? Could you do some examples with simple pictures ? This would help us to understand how you fell it. Is a group the number of boxes that can be on the same bitmap with the same name ? Or anything else ? I hope the allowed numbers you decided will be enought for animated characters. I don't know since I don't really understand how you want to manage it.

[CrimsonCasio]

im trying to think how we would implement the clsn boxes... mabey:

SPRT.BOX(1)={1,1,8,8} // sets first clsn box to go from 1,1 to 8,8 (positions relative to sprite)

then for CLSN: i think we need 2 types of CLSN functions, we're trying to jam to much into a single function.

CLSN: accepts a sprite and returns pointers to all sprites touching it

#CLSN <sprite> <pointer array>

note: i forget if we can do pointer arrays, so i have a workaround below.

BHIT: takes two sprites and returns a list of boxes that are touching.

#BHIT <sprite> <sprite> <array>

CLSN can be used as a quick check to see if a BHIT is even needed in any given circumstance, and it allows for much more flexibility.

--> Workaround for pointer arrays:
if we cant do pointer arrays, we can do this instead, give each sprite an ID property, and create a function that can retrieve a sprite given its ID. ex:

CLSN ^SPR1 @A // A is given all IDs of sprites touching SPR1
#SPID @A(1) *SPR // gets a pointer to a sprite using its ID
#BHIT ^SPR1 *SPR @BOX // gets all touching boxes in the two sprites

btw, fogive me if im using outdated sentax

[huhn_m]

I would wait till we have the beta before discussing such advanced things. I'm working quite hard on this now and there should at least be an proof of concept by the weekend.

Actually the main problem is the compiler since it needs quite some work. The VM is getting better and better

[Deimos]

That's some good news. I can't wait to see MLC2 in action

[burntfuse]

You're making me guilty - I haven't even finished the tokenizer for MLC1.

[huhn_m]

me neither

the first release will only be a proof of concept so it will only be of worth for you if you can code in the bytecode (doc only in german atm ) but it should have some functions (and even some additions to the doc I have a working version right in front of me. The only thing that is not tested is grayscale since it does not work with WG100 and I can't connect the calc to the Notebook and since most of the coding I do at work I can't test ... had no time yet

[SRM]

Sweet, very good news !!!

Huhn_m, did Crimson give you the CLSN docs ? I wish he did it. I hope it will help you better to understand all what I tried to explain (most are in page 2 and 3). I'd like to make my MLC street fighter game better.

[huhn_m]

nope. only his post above ...

[CrimsonCasio]

CLSN Docs? o_O

[SRM]

Crimson, look at your e-mail. It should be there. Else, Huhn_m, could you give me your mail by PM.

[CrimsonCasio]

eh... do you have any idea how long its been since i looked at my e-mail... im gona have to sort though pages of crud to find it >_<

[huhn_m]

Sorry for the delay but just to keep you up to date:

Implemented:

Timer, (Delay ... basics for time based functions)
Text function
WaitKey function
HALF function
CLRS function
Mouse support (together with keyboard, partial)

Since I figured that only the bitcode interpreter is not much use and
since coding goes so smoothly the last days I decided to also code
the compiler before the first beta. Since most of the MLC2 users probably don't even know ASM I don't think they can cope with the sole numbers in the bytecode.

So the next target is the 14th of November for the real first beta, with a working compiler. (99% also with function support already but probably no real graphics functions (sprites, lines etc) so still more a proof of concept.

Btw. has anyone a GOOD source for a line drawing routine is ASM for the AFX (NOT one that draws each pixel seperately! It should be fast) since this would ease my pain a little. Also not hline or vline but a REAL line algorithm.

[Marco]

In the case you still use AFXGFX: there's a line drawing routine included already (next to a fillcircle - routine), though I think I didn't put it into the public version available in the file sharing (I could send you that "inofficial" version if you want)

The Line routine doesn't draw each pixel seperately but assembles lines out of several HLines (or VLines, if the line is more than 45 degrees). I didn't put the routine into AFXGFX public version because I haven't translated it into assembler, it's pretty fast nevertheless (around 100 to 200 lines from top left corner of the screen to bottom right) cause the V- / HLINE routines are made in assembler (maybe you also could rewrite the algorithm in assembler completely but I think it wouldn't be much faster as most time is consumed by V - / HLine subroutines anyway)

[huhn_m]

yeah, please PM or mail me the code.

No, I don't use the pascal libraries any more since I'm just not good enough in pascal to acchieve this project. I use 100% asm now and it works

I only need some routines that are difficult to do (like the line routine)

[Deimos]

Could You update the keboard doc with description of how exactly mouse support is goung to look like?
And what does the HALF functio do? I couldn't find it in the doc.

[burntfuse]

I've been working some on the 86 interpreter, and there's some stuff I need to know before I can continue too much further:

I looked in the updated documentation and couldn't find anything about array types...is it '#arry %intarry,5', then?
Can chars be treated as ints? (so huge lookup tables aren't needed for printing chars in order, for example)
What's the max length of varnames and function names?
Are there plans for modulus, AND, and OR operators?

Also, the pointer should have a dereference operator ('*ptr=3' instead of 'ptr.=3', for situations like '%int=*ptr+1', '#pixt 20,30,*ptr', etc.)

[huhn_m]

1) HALF means HALT ... type
2) Array: see the docs ... it is in there from the update 2 weeks ago... the array char plush the type char (so 2 prefixes)
3) Chars as ints... yes. I do this. But the compiler has to do range checking
4) Max lengths. I set it for 14 chars for me. Ultimately the length doesn't matter but only the first 14 chars are used to differ the function
so MLC2RocksMyBoxers
is the same as MLC2RocksMyBoxes
5) These are in the VM (already implemented ... don't know if it will be in MLC2 .. do we need them? If yes how do you want them. You can decide too! Its not only my project )

[Marco]

PM sent

Btw. you really write *everything* in assembler? Even the compiler??

[huhn_m]

yes I do ... its fun and I just LOVE asm.

It is also good practice sine I want to write a native 64-Bit OS for my new machine (just for working. E.g. easy word processor, spreadsheet and so on. This is a lot of fun (for me) and will be a hyper-fast, instant on os!

[SRM]

I really like to hear that MLC2 will be entirly written in ASM. It will be so fast !!! How much times would it be possible to be faster than MLC1 ? There won't be anymore balance between speed and complexity for games.

Just a question : I know the max int values (+-32 000) are given by the bit numbers of the processor. However, couldn't there be a way to increase this number limit for specifics vars ? Or using floating points. In some case, it's necessary. Or a way to have real numbers (3,4) more easily than using DX and VX ? If someone has a great idea ... Say it.

[huhn_m]

no way. No floating point for the AFX since it has no FPU and I neither intend to nor want to write an fp -lib for it (since I can't and since it will slow down things too much).

At most fixed poiint maths but I don't think so, too easy to implement, would shed the roots of the engine (nearly complete rewrite needed, verry complex ... not with me. Sorry )

[Marco]

Do you use NASM or TP inline assembler? For inline assembler you could use Pascal FPU emulation, for NASM you could dissassemble TP FPU emulation routines (but I also advise against it, FPU emulation is slow, too slow for games at least).

How much times would it be possible to be faster than MLC1 ?

Well, don't know MLC1 performance, but if he still uses the framework we worked out for the VM when I still was in the project it should make around 140k ADD instructions a second.

[huhn_m]

same syntax, same bytecode format.

So yes. 140K or faster

I use TASM btw and for AMD64 I use FASM (only one with curremt builds, I use the one from last month)

[SRM]

Someone could ask 4nic8 how fast MLC1 is ? This would give us an idea of the speed evolution between the two versions.

[Deimos]

(modulus, AND, OR)
5) These are in the VM (already implemented ... don't know if it will be in MLC2 .. do we need them? If yes how do you want them. You can decide too! Its not only my project )

I think that we do need modulus, it can be quite useful. I would also like to see a function computing absolute value in mlc2 - it was one of the things i wanted to see since mlc1.
IMO logical operators would be really nice to have too.

[burntfuse]

Yeah, we left them out of the first version of MLC (except AND), which I realize now was a big mistake. Maybe the '|' char for OR, '&' for AND (as long as the casios and HPs have those chars too), and I don't know what for the modulus, since '%' is already the int var character...

2) Array: see the docs ... it is in there from the update 2 weeks ago... the array char plush the type char (so 2 prefixes)
3) Chars as ints... yes. I do this. But the compiler has to do range checking
4) Max lengths. I set it for 14 chars for me. Ultimately the length doesn't matter but only the first 14 chars are used to differ the function
so MLC2RocksMyBoxers
is the same as MLC2RocksMyBoxes

OK, MLC1 arrays will just have the var type prefix (because I'm lazy and don't feel like writing all the extra code ), char values will wrap around after 255, and 14 chars would take up too much mem on the 86, so that'll be cut down to 10 in MLC1. What does everyone else think about the pointer dereference operator? Sorry, one more question:

Will numbers be allowed in string expressions? ($STR="Score: "+%SCORE / $STR=3+4 / etc.) They were in the first version of MLC, and ended up being very useful. BTW, the result of the second expression would be "34", not "7".

<offtopic>
You're writing your own OS in ASM?!?!? *bows down in awe*
</offtopic>

Edited by burntfuse, 10 November 2005 - 07:40 PM.

[huhn_m]

Operators. Possible. I think I could do them. I'm currently doing the Function handling for the compiler. Once this is done there should be
the first beta out ... sorry for the delay but had some problems at
work and stuff (and the PC upgrade and so on ...)

Still, there is one thing left. I need a GOOD coder who can write a dedicated editor for MLC2. Else the whole thing is quite shaky.I don't like the way it was done in MLC1 (with replacing and stuff).

So if there is any ASM/C coder for the AFX out there who feels capable to write such an editor feel free to do so. No limitations (Pascal allowed etc. )
No interface things. Just an editor. (Though tooken selection would be nice but is not allowed).

Numbers in expressions. No. At least not in the first version. Use the ITOS (Int To String) function instead. The translation should be similar so maybe
we'll add direct concatentating (sp?) later.

OS: Wait ... I'm still reading the AMD64 Bit system programmers manual and it is quite badly written (repetitive, to many text, to few examples, but I think the most tricky part is to get the damn CPU in long mode. Once this is done everything should be fine. I just want a FAST working environment (graphically, VESA based or so) that has an instant on effect and is 100% optimized to the dual core Athlon64 (though I still need to find dual-core docs )

[CrimsonCasio]

found and resent the CLSN docs

[huhn_m]

thanks. got it

[SRM]

I hope those docs show you well what I meant.

I'm prepared to test the beta. Let's gooooo.

[huhn_m]

does anyone want to do the editor?

[Marco]

An idea for the editor [but I won't do it]: make it an IDE!

It's not that hard to implement, could be this like: Press F6 in the editor and it will remove itself from memory and start the compiler with passing the name of the file to be compiled as a command line argument.

The compiler compiles the source then and starts the interpreter (with the bytecode file's filename as a command line argument) if no error occured. If an error occured during compilation, it will remove itself from memory and start the editor again, passing the filename of the source and the position within source where the error occured as command line arguments. Using this arguments the editor scrolls down directly to the position where the error was and you can fix it.

This way you had fine edit->compile->test->edit - cycle like in a real IDE, so finding / removing errors in source also would be much easier and faster

[huhn_m]

lets do a simple editor first ... we could mod it later on.

[Deimos]

I'd love to see an ide too, half of the time i spent programming in MLC1 was wasted for switching between basic editor and MLC interpreter.
But unfortunately i can't offer writing an editor - i have very little spare time recently, and i'm still not very good at C programming.

[huhn_m]

Just an announcement:

I recently said that I would make MLC2 open source. after throughly reading on gnu.org. I decided against it.

I now intend it to be Free Software.

See these sites for the reason:

http://www.gnu.org/p...or-freedom.html
http://www.gnu.org/g...ux-and-gnu.html