Jump to content



Photo
- - - - -

Documentation Discussion


  • Please log in to reply
84 replies to this topic

#1 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 24 September 2005 - 06:50 PM

Hello and welcome to our new discussion forum :D

Here are th links for the old documents:


http://www.earthforg...nm/MLC21012.pdf (PDF FOrmat) UPDATED again
http://www.earthforg...nm/MLCIIDEf.odt (OpenOffice.Org 2.0 odt FOrmat)

The doc is based on the syntax.txt of the TI project:

http://www.earthforg...uhnm/syntax.txt (TXT format)

And here is the later added Keyboard description:

http://www.earthforg.../huhnm/MLC2.doc (Keyboard)

The overhauled document will be available either this night (CEST) or tomorrow.

Post your ideas, comments and critics!

Everyone is invited to discuss, not only the ones who write the MLC2 interpreter but also
those who want to code in it and/or discuss it! Feel free to post! I want to see this topic glowing!

#2 Deimos

Deimos

    Casio Freak

  • Members
  • PipPipPipPip
  • 107 posts
  • Location:Poland
  • Interests:3d modelling, paper models, BASIC programming-AFX (just beginning)

  • Calculators:
    AFX 2.0+

Posted 25 September 2005 - 03:09 PM

I have a question about bitmaps: how are they going to be defined? Do we have to create an array containing bitmap data, and then assign pointer to this array to bitmap.ptr with something like this:
[BITMAP.PTR^=@ARRAY
Or did i misunderstand it all? :P

#3 Marco

Marco

    Casio Freak

  • Members
  • PipPipPipPip
  • 185 posts
  • Location:Dresden, Germany

  • Calculators:
    Casio CFX 9850G (broken),
    Casio CFX 9850GB,
    Casio Algebra FX 2.0 Plus

Posted 25 September 2005 - 08:41 PM

Ah you moved it to the UCF - that's fine :greengrin:

How far is the project's current progress?

Deimos you were really busy today as I see :)
Is there already a beta of MLC 2.0 interpreter available?

#4 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 25 September 2005 - 09:45 PM

Hey marco!

No, I've no beta since I first wanted to make a clear doc. that every developer uses as a guideline in order to reach like 100% compatibility but the TI devs seem to have faded and so I moved the discussion here and once everything is done I'll only do it for the casio and once the TIs want it they must live with what we have :D

Only burntfuse is interrested and develops some kind of mutant language that is sth. between MLC1 and 2 for the 86 since this calc is not 100% capable of MLC2.

Of course you can, like all others always contribute to the process ... (and help me develop it further if you have the time. Maybe I need your help from time to time.

I've got the new doc but catched a cold so that I was not in the mood to convert and upload it. Maybe tomorrow or so :D

Cu & good night huhn

#5 Orwell

Orwell

    Casio Overlord

  • Members
  • PipPipPipPipPipPipPip
  • 777 posts
  • Gender:Male
  • Location:Paris - France

  • Calculators:
    Casio AFX 1.02 / Casio ClassPad 300

Posted 26 September 2005 - 10:53 AM

(Thinking about that, a Lua interpreter for AFX would be great. But I didn't say anything... :P )

#6 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 26 September 2005 - 12:40 PM

can you write it?

I don't know lua ... have any good tuts? But this is off-topic. Please continue such discussion in the AFX/CFX forum

#7 SRM

SRM

    Casio Addict

  • Members
  • PipPipPip
  • 77 posts
  • Location:France

  • Calculators:
    G 100

Posted 27 September 2005 - 02:26 PM

I had a question on the epic forum that you didn't answered. It's about CLSN with transparent colours.

I'd like an option on CLSN that would decide if a transparent colour of a sprite is used or not.

So
#CLSN ^A,^B,%A,0 : transparent colour isn't used by the function to verify if sprites are touching.
#CLSN ^A,^B,%A,1 : transparent colour is used by the function to verify if sprites are touching.

This way, it would be easier to detect if sprites are near or not, as to detect if they are touching.


I hope lots of guy will join !!! :greengrin:

#8 Deimos

Deimos

    Casio Freak

  • Members
  • PipPipPipPip
  • 107 posts
  • Location:Poland
  • Interests:3d modelling, paper models, BASIC programming-AFX (just beginning)

  • Calculators:
    AFX 2.0+

Posted 27 September 2005 - 02:44 PM

Another thing that could be useful is a function that would return current date/time. We decided that there wil be a timer that can count time in 1/100 of a seciond, but it would be useless for measuring long time intervals, like minutes or hours. Having a real time clock support would also allow eg. to check the time from last program execution.
Of course it wouldn't have to keep refreshing all the time. If refreshing was manual (by calling a proper function), it shouldn't slow down the program if the clock is not used.
Time could be an object with properties like:
TIME.Y //Year
TIME.M //Month
TIME.D //Day
TIME.WD //Weekday(int 1-7)
TIME.H //Hour
TIME.M //Minute
TIME.S //Second

#9 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 27 September 2005 - 08:07 PM

time can be done. It would be read directly from the HW Clock.
But I don't know if it is possible on the TIs

CLSN:

I'm not sure. ... depends on how easy this is to implement and on how fast this function would be. I think it does not really make sense to use it since
you can define bitmaps of any size ... so why detect a big border?

#10 Guest_burntfuse_*

Guest_burntfuse_*
  • Guests

Posted 28 September 2005 - 12:43 AM

Unfortunately, no clock on the TIs (except for the 84+/SE and 89 Titanium). The TI interpreters could just ignore the clock commands, though, or return all 0s.

The modification for CLSN seems sort of pointless to me, you can just compare the coordinates of the sprites instead - it's a lot easier to do! ;)

#11 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 28 September 2005 - 06:30 AM

no. then also no clock on the casio.

right. so no changed CLSN.

#12 SRM

SRM

    Casio Addict

  • Members
  • PipPipPip
  • 77 posts
  • Location:France

  • Calculators:
    G 100

Posted 29 September 2005 - 01:20 PM

CLSN:

I don't agree with you.
To detect if a missile touch a plane, the CLSN must detects if untransparent parts are touching. It would be stupid if the plane explodes while the missile doesn't touch.
However, in a WarGame, units have to see other units to fire. They don't have to touch. In this case, The transparent mask would represents the watching distance. Then if the transparent mask of a unit touch the ennemy, we can say they can see each other.
I don't see other simple way to do it. Making a calculation of the distance between each unit at every increament time would take so much time if there are lots of units (n*(n-1) calculations).

#13 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 29 September 2005 - 05:11 PM

I don't aggree with you SRM.

It is a huge waste of memory to do such a thing as a watching distance via
the transparent mask. Lets say you want a distance of 16 pixels arround a 8x8 tank.

This would lead you to a watching distance size of 24x24 Pixels - 8x8 pixels
this makes 1536 pixels. Given that 2 pixels do fit in one byte this will make a total waste of 768 yte for this one tank. Lats say you have 10 different of those.

So you waste 7.7KB just for a work possible with coding.

I have a better suggestion that comes quite close to your idea but that is implemented using a different way the map system works.

Maps can now be drawn at any place and are an array of Bitmaps (But not sprites! Needed because of the speed limits...).
Then you can create a 16x16 bitmap that is only transparent and check for the collision of this new map.

...

I think this does not sound too plain ... so I better include more example in the new map section.

For the misle plane problem ... this is dumb. Just make the plane so that it is nearly as big as the sprite (or you could also create a mp
to make seperate wings ...) and then check this map or sprite for collision. This is quite easy and not so memory wasting.

I see when I have done the new documentation and will upload it ASAP.

Cu Huhn_m

#14 Deimos

Deimos

    Casio Freak

  • Members
  • PipPipPipPip
  • 107 posts
  • Location:Poland
  • Interests:3d modelling, paper models, BASIC programming-AFX (just beginning)

  • Calculators:
    AFX 2.0+

Posted 29 September 2005 - 09:55 PM

I just wanted to say a few comments about this tread:

http://dysfunction.e...p?showtopic=413

I would recommend to wait with programming till at least one programmer for each platform has confirmed that the
implementation is possible the way the docs want it. Else changes to the syntax / feature set m?ght be needed.


I sure agree with You, huhn, we want to keep all the versions 100% compatibile after all, but i think that You might start thinking about releasing v0.1 version of MLC2, with only a basic commands known from MLC1, like:
#TEXT
#PIXL
#PIXT
#LINE
#IIFF
#DRAW
#FORL
#LFCT
#WFCT
basic integer variables support

and maybe
#RECT

All these functions proven to be useful in MLC1, and all MLC2-capable calcs should handle them without any problems. More advanced functions and features like pointers, arrays, bitmaps, maps, sprites or strings could wait until they're comfirmed by other programmers.
Having the initial version would give us a goot feel of MLC2 speed in compansion to MLC1, and would probably allow You to eliminate a few bugs.

#15 SRM

SRM

    Casio Addict

  • Members
  • PipPipPip
  • 77 posts
  • Location:France

  • Calculators:
    G 100

Posted 29 September 2005 - 10:26 PM

Question : How do you think CLSN will run ? I don't know how it's used on TI. If we don't have the choice (option 0 or 1), I prefer that the transparent colour to not be taken in acount to check if sprites are touching. The plane exemple is only an exemple, I had the same problem with Street Fighter : characters couldn't hit the other one because CLSN on MLC 1 only checks if rects around sprites (8*8 or 16*16) are touching and not if drawings are touching. So it's no use. :(

I'd like to have a usefull CLSN :)

Do you understand what I mean ?

#16 Marco

Marco

    Casio Freak

  • Members
  • PipPipPipPip
  • 185 posts
  • Location:Dresden, Germany

  • Calculators:
    Casio CFX 9850G (broken),
    Casio CFX 9850GB,
    Casio Algebra FX 2.0 Plus

Posted 30 September 2005 - 08:24 AM

For CLSN, note that it wasn't only a big waste of memory only if CLSN detects wheater 2 sprites' untransparent parts are touching, but speed also would be a big problem. For each non-transparent pixel of the one sprite you needed to check if it's overlapping a non-transparent pixel of the other.

Instead of, CLSN should just check if the sprites' rectangular areas are overlapping or not, that's easy to do, it's fast and doesn't need memory (just check each corner of the one if it's inner the other's ares).

Though I really agree SRM's argument:

To detect if a missile touch a plane, the CLSN must detects if untransparent parts are touching. It would be stupid if the plane explodes while the missile doesn't touch

So I suggest a new "PXLT" command that is applyable on sprites/bitmaps, not to the screen. PXLT <bitmap/sprite> <x> <y>, (or <bitmap/sprite>.PXLT <x> <y>) returns TRUE if pixel x,y is non-transparent, FALSE otherwise. As it checks ONE pixel only, it's fast. You also could change CLSN that way that it doesn't do a complete check with all pixels, but performs 4 times a PXLT, one for each corner only.

#17 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 30 September 2005 - 12:05 PM

I don't aggree with the new PIXT command.
You should know how far they have to overlap.

You can simply check if the collide and if they do you do also
check how far (by calcing the diff between the coordinates. You know that if the diff is -8 and both have a transparent area oif 4 pixels that they MUST be touching.

#18 Marco

Marco

    Casio Freak

  • Members
  • PipPipPipPip
  • 185 posts
  • Location:Dresden, Germany

  • Calculators:
    Casio CFX 9850G (broken),
    Casio CFX 9850GB,
    Casio Algebra FX 2.0 Plus

Posted 30 September 2005 - 02:47 PM

But what e.g. about a bullet and sprites with a transparency mask like that:

Object
0/0...........0/m
........XXXXXXXXX
XXXXXXXXXXXXXXX..
..XXXXXX.........
...XXXXXXXX......
.....XXXXXXXX....
...XXXXXXX.......
n/0...........n/m
Should'nt the bullet "hit" the object when it collides with an X only instead of when it passes the rectangle (0,0,m,n)? This could be done by a PXLT command only. Imagine the bullet:

0/0....0/w
....XXXXXX
..XX.....X
.X.......X
..XX.....X
....XXXXXX
h/0....h/w
Bullet at Position (x,y), the object at position (a,b ). To determine wheather The bullet hits the object, CLSN just needed to do 4 pixeltests commands, one for each edge:

CLSN = Pixeltest(object,x-a,y-b) || Pixeltest(object,x+w-a,y-b) || Pixeltest(object,x-a,y+h-b) || Pixeltest(object,x+w-a,y+h-b)
It doesn't deliver the distance but just wheather two object collide, but what do you need the distance for?

#19 Orwell

Orwell

    Casio Overlord

  • Members
  • PipPipPipPipPipPipPip
  • 777 posts
  • Gender:Male
  • Location:Paris - France

  • Calculators:
    Casio AFX 1.02 / Casio ClassPad 300

Posted 30 September 2005 - 02:48 PM

Just a question (by curiosity :P)

We decided that there wil be a timer that can count time in 1/100 of a seciond

How are you planning to do that on the AFX? =)

#20 Deimos

Deimos

    Casio Freak

  • Members
  • PipPipPipPip
  • 107 posts
  • Location:Poland
  • Interests:3d modelling, paper models, BASIC programming-AFX (just beginning)

  • Calculators:
    AFX 2.0+

Posted 30 September 2005 - 05:01 PM

Oops, it was suposed to be 1/10 of a second.

#21 Orwell

Orwell

    Casio Overlord

  • Members
  • PipPipPipPipPipPipPip
  • 777 posts
  • Gender:Male
  • Location:Paris - France

  • Calculators:
    Casio AFX 1.02 / Casio ClassPad 300

Posted 30 September 2005 - 05:30 PM

Oh, okay then ;)

#22 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 30 September 2005 - 08:51 PM

1/100 would also be possible. Only that some times will never occur since the internal timer is not exact enought :D

#23 Guest_Guest_*

Guest_Guest_*
  • Guests

Posted 30 September 2005 - 09:57 PM

Why don't we keep CLSN the old way, where it only detects collisions between non-transparent sections of sprites (for testing if a bullet hit a plane, for example)? Then if you want to see if SPR1 is within a certain distance of SPR2 (for seeing if one tank can "see" another, for example), you can do something like this:

#IIFF ^SPR1.X+%DIST>^SPR2.X
#FEND
#IIFF ^SPR1.Y+%DIST>^SPR2.Y
#FEND
#IIFF ^SPR2.X+%DIST>^SPR1.X
#FEND
#IIFF ^SPR2.Y+%DIST>^SPR1.Y
#FEND
//IF IT GOT HERE, THEY'RE CLOSE TO EACH OTHER

I'm sure it could be optimized to take up much less space and execution time, this is just something I came up with on the spur of the moment (and even as it is, it wouldn't slow down the program very much). This way, it'll be a nice fast solution without having to make sprites fill their boundaries or huge sprites with only a small non-transparent section or test pixels individually or anything else that makes it unnecessarily complex.

#24 Guest_burntfuse_*

Guest_burntfuse_*
  • Guests

Posted 30 September 2005 - 09:58 PM

Sorry, that was me.

#25 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 01 October 2005 - 08:32 AM

But only testing the non transparent pixels is VERRY time consuming since the pixels first have to be checked if they are transparent and checking individual pixels is always slow.

I'd much prefer marcos way.

And for the distance thing. The problem is that you have to check this for 4 directions in order to represent the radius. This is extremely slow. Maybe it is better to implement some kind of pseudo collision detection with "Line of sight" feature

I'll think about this.

#26 CrimsonCasio

CrimsonCasio

    UCF Ambassador

  • [Legends]
  • PipPipPipPipPipPipPipPipPipPip
  • 3579 posts
  • Gender:Male
  • Location:USA
  • Interests:Claculators, Stephen King, Video Games, Calculators, Programming, Calculators, Reading, Calculators... hmm, what else... Ah! Calculators!

  • Calculators:
    Algebra FX2.0, CFX 9850Ga+, Classpad 300

Posted 02 October 2005 - 04:15 AM

i am beyond impressed with everything thats gone on here... sigh... i knew MLC was to good to die out and it seems i was more than correct. its going to take me a while to absorb all this :P

#27 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 06 October 2005 - 07:40 PM

i updated the documentation (at last :D) and included some of the things discussed. Don't pick at me ... I'll include the others later.

For now: Some changes arround here:

1) I won't update the doc till the version 0.1 as suggested by deimos, is released. I also set up the release schedul. Please let only me edit it.

2) I made a new pinned topic about the suggestions. Please do post your suggestions with a short description and 1 or more example(s).
Please do not discuss them. For discussion open a new topic. All discussion or arguments about the function or current functions will be deleted.
You can discuss this in another topic and then update the suggestion.

3) I will set up an CVS server at my PC the thing is that I'm not allowed to keep my PC running all the time so you might not be able to access it. Once it is set up I'll make a new topic with the online times. In this time you can access the server. Once the time has come you'll get your logins and the address of the server ... thanks.

#28 Deimos

Deimos

    Casio Freak

  • Members
  • PipPipPipPip
  • 107 posts
  • Location:Poland
  • Interests:3d modelling, paper models, BASIC programming-AFX (just beginning)

  • Calculators:
    AFX 2.0+

Posted 07 October 2005 - 02:43 PM

2) I made a new pinned topic about the suggestions. Please do post your suggestions with a short description and 1 or more example(s).


Actually, it's a pinned and closed topic. Was it intended to be that way, so that only moderators can post, or was tihis just an accident?

You're giong to write a mlc editor too? That's great. Maybe create a new tread for discussion about it?

Anyway, i'l' read the updated doc soon, and let You know what i think.

#29 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 07 October 2005 - 09:23 PM

the topic automatically opens the 16th because I'm too busy now to review it and on holidays the next week. (last time for the next 6 months :D )

then it will open automatically and let everyone post. If you feel like posting now then go ahead but it should be really an exception :D

#30 burntfuse

burntfuse

    Newbie

  • Members
  • Pip
  • 12 posts

  • Calculators:
    TI-86
    TI-85
    TI-83+

Posted 08 October 2005 - 08:46 PM

OK, now I understand PXLT. Sounds good...what would the syntax be?

#31 burntfuse

burntfuse

    Newbie

  • Members
  • Pip
  • 12 posts

  • Calculators:
    TI-86
    TI-85
    TI-83+

Posted 16 October 2005 - 10:05 PM

Umm...anyone have suggestions for the syntax of PXLT? :banghead:

Also, for arrays, maybe instead of having a special array char, we could do sort of like in C/C++/Java/etc. and have the array's char be the type of var it's storing? For example:

#ARRY %INTARRY,10
%INTARRY=(1,2,3,4,5)
%INTARRY(0)=7
#ARRY $STRARRAY,5
$STRARRY(0)="String 1"
$STRARRY(1)="String 2"

Sound good, or is the current system better?

#32 Deimos

Deimos

    Casio Freak

  • Members
  • PipPipPipPip
  • 107 posts
  • Location:Poland
  • Interests:3d modelling, paper models, BASIC programming-AFX (just beginning)

  • Calculators:
    AFX 2.0+

Posted 17 October 2005 - 12:37 PM

#ARRY %INTARRY,10
%INTARRY=(1,2,3,4,5)
%INTARRY(0)=7
#ARRY $STRARRAY,5
$STRARRY(0)="String 1"
$STRARRY(1)="String 2"


I think this would be a good solution. As long as we had only integer arrays, the old soluion with special array sign worked fine, but now with multi-type arrays i think it would be better to make it the way burnt proposes.

#33 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 18 October 2005 - 09:17 PM

read the doc! the second version already contains such a sugestion ... (quite similar though more easy for the programmer of the compiler)

#34 SRM

SRM

    Casio Addict

  • Members
  • PipPipPip
  • 77 posts
  • Location:France

  • Calculators:
    G 100

Posted 19 October 2005 - 05:31 PM

Hello guys,

Since I finished my studies, I don't have an internet connexion as often as before. So I'm sorry for not being here very often. I keep an eye on the project, but I can't answer at each time. Actually, the project become more and more difficult to understand because we don't have any support to test. Don't think I'm leaving the project. I'm standing for a beta version to see how everything go on.

I've just read again the doc, and there's a missing about sprites : there isn't a flip mode (or mirror) on x and y axis.

I'd like to know how the CLSN problem will be finally issued. I propose something like in MUGEN (a street fighter editor on internet). We can edit some cases (CLSN) on a sprite, and then only check those reduced CLSN (there can be one case or more). So, for a street fighter game, there are 2 CLSN on a sprite : one describe the attack part of the sprite (a case around the punch), and the other the weak part of the sprite (a case around the body). This allow to describe better importants parts of a sprite. This mean the CLSN specification should be changed to define the CLSN location on the sprite. Perhaps it should be associated directly to bitmap, and then in the graphic editor. I think this methode solves all the problems we had because it's near as simply to do and time consuming as it was before and it is efficient. What do you think about it ?

#35 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 19 October 2005 - 07:57 PM

but is it memory efficient? If I understand you correct you need a second map for the attack part. Though this map does only need 1 and 0 it is still quite big if the sprite has a big attack radius.

I don't think that we should take away too much work at the cost of lots of memory.

For filp mode: For what is it used? I didn't see a sense in it ...

#36 SRM

SRM

    Casio Addict

  • Members
  • PipPipPip
  • 77 posts
  • Location:France

  • Calculators:
    G 100

Posted 20 October 2005 - 06:45 PM

There's no memory need for the CLSN I talk about. You only have to save the two points needed to make a box (rectangle) and to name this box by a number. Then, when the prog ask for a CLSN to check between 2 boxes (or more), you check if the 2 boxes touch or not. This way, you don't have to think about what is in the box (transparent pixels or not) because it's only a drawing. The boxes are some approximations of the needed area. It's the programmer that defines the importants parts of his bitmaps. I don't think there will be more than 3 or 4 CLSN boxes on 1 bitmap.

About the street fighter example I talk:
The offensive character have 2 boxes : one for the body, the other for the punch.
The defensive character have only 1 boxe : for the entire body.
If the punch box of the offensive character touch the body box of the defensive character then he hits.
No box is drawn unless if we add a function to show them (only for the game development like DRCL : draw CLSN boxes).

So you don't have to check the pixels in the boxes, only the boxes's edges. There's not much memory waste (for each box : 4 coordinates by box : x1, y1, x2, y2, and the box's name) and this must be really fast.

This CLSN system allow to have specifics parts on 1 bitmap, and, for example, to destruct only 1 part of a plane each time you launch a missile. I think there could be lots of applications.

Don't forget that the boxes's coordinates depend on the bitmap coordinates.

I think the best way to define those boxes is to implement their edition in the bitmap editor. So boxes and their name are added directly to the bitmap description.

For the programmer, he associates bitmaps to a sprite like we do for now. After, a CLSN check is like that :

CLSN <sprite 1>,<box number (name) of the associated bitmap>,<sprite 2>,<box number of the associated bitmap>,<%var>

If, on each bitmap, the name 1 is given to the body box, and the name 2 is given to every attack boxes, you could have the code bellow to check if the sprite 1's attack (that contain an attack bitmap and so an attack box) touch sprite 2's body (that contain a body bitmap and so a body box) :

CLSN ^sprite1,2,^sprite2,1,%TOUCH

So names are int numbers. The same name can be given to different boxes of a bitmap if the programmer thinks they have the same function. In this case, the CLSN function would check every boxes of the bitmap of the sprite that have the same number. So the speed of the CLSN function would depend on how much boxes with the same name the programmer gives to his bitmaps. We must warn him about how it works so that he won't abuse on the boxes number.

On the same bitmap, a box named 1 can cut a box named 2 with no error. Their size and position are free in the bitmap.

If a called box doesn't exist, there's no error, the interpreter pass through the CLSN call.

Here are some stuffs about the mugen'CLSN:
http://www.angelfire...er2/sykchar.htm
http://www.geocities...enrealm/air.htm
If you're interested, I can give you the tools needed in those tutorials.



About the flip mode, it's the same use than rotation. What's the interest of the rotation ? Only to reduce the memory needed : Only one bitmap is used to show 4 bitmaps with different angles, doesn't it ?
The flip mode allow a character to look right and left (so 2 bitmaps) with only 1 bitmap. It's the vertical flip. To follow this way, we can add an horizontal flip and a mixed vertical and horizontal flip (that is like a 180? rotation). At first, Marco was OK with it. I hope you'll agree it.

If the box CLSN system I talk about is adopted, don't forget to make the boxes to follow the bitmap motions.

#37 huhn_m

huhn_m

    Casio Maniac

  • [Legends]
  • PipPipPipPipPipPipPipPip
  • 1957 posts
  • Gender:Male
  • Location:Germany / Dresden
  • Interests:Assembler(!!!)
    Computers and Programming
    Operating Systems
    Programmable Calculators
    Maths and everything arround it

  • Calculators:
    FX-82SX / AFX 2.0+ (ROM 1.03) / FX 1.0+ (ROM 1.03)

Posted 20 October 2005 - 07:24 PM

WOW!!! The CLSN is perfect I did never think of such a way though it is so simple ... like hit boxes

and OK... I saw the need of the flip mode ... (though I didn't see the flip flag in the TI versions documentation but this is the reason why we write a REAL documentation, isn't it?

#38 SRM

SRM

    Casio Addict

  • Members
  • PipPipPip
  • 77 posts
  • Location:France

  • Calculators:
    G 100

Posted 20 October 2005 - 08:02 PM

:D :D :D

I hope the system to give a name to boxes won't be a problem (the name can be an int, a var or a pointer when we call it, but not in its edition). In the case of a plane that launch 2 missiles, there could be 2 boxes with the same name on the same bitmap. So be carefull programming it.

It's really important that the boxes follow the sprite/bitmap motion on a displacement, a rotation and a flip. Those functions have been created to reduce the bitmap's number. So if we use those, there won't be flipped bitmaps with the good boxes. Do you understand what I mean ? That's an other case where the box number should be short if we want the games to stay fast. So the programmer has to simplify the most he can the box area ("is this pixel really important to make an entire box for it ?").

I think it's important for you to read the tutorials I marked. This way, you can have concrete examples about how to put the CLSN boxes in the DATA section.

This part, in the documentation, must be really well explained with graphics.

#39 burntfuse

burntfuse

    Newbie

  • Members
  • Pip
  • 12 posts

  • Calculators:
    TI-86
    TI-85
    TI-83+

Posted 20 October 2005 - 08:56 PM

read the doc! the second version already contains such a sugestion ... (quite similar though more easy for the programmer of the compiler)


I did read it and couldn't find anything about it in there... :unsure:

Great idea for the "hit boxes", I can't keep up with it right now but it seems like a good solution.

One more suggestion: maybe instead of having labels as "#FNCT x", we could do "x" or ":x" or something? It would be easier on the user and interpreter.

#40 CrimsonCasio

CrimsonCasio

    UCF Ambassador

  • [Legends]
  • PipPipPipPipPipPipPipPipPipPip
  • 3579 posts
  • Gender:Male
  • Location:USA
  • Interests:Claculators, Stephen King, Video Games, Calculators, Programming, Calculators, Reading, Calculators... hmm, what else... Ah! Calculators!

  • Calculators:
    Algebra FX2.0, CFX 9850Ga+, Classpad 300

Posted 21 October 2005 - 04:20 PM

i like the sound of the CLSN now, seems a good way to accomplish everything i can think of wanting to do, and it might even allow for some other things i hadnt planned on. :D


2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users