Documentation Discussion
#1
Posted 24 September 2005 - 06:50 PM
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
Posted 25 September 2005 - 03:09 PM
[BITMAP.PTR^=@ARRAY
Or did i misunderstand it all?
#3
Posted 25 September 2005 - 08:41 PM
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
Posted 25 September 2005 - 09:45 PM
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
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
Cu & good night huhn
#5
Posted 26 September 2005 - 10:53 AM
#6
Posted 26 September 2005 - 12:40 PM
I don't know lua ... have any good tuts? But this is off-topic. Please continue such discussion in the AFX/CFX forum
#7
Posted 27 September 2005 - 02:26 PM
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 !!!
#8
Posted 27 September 2005 - 02:44 PM
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
Posted 27 September 2005 - 08:07 PM
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_*
Posted 28 September 2005 - 12:43 AM
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
Posted 28 September 2005 - 06:30 AM
right. so no changed CLSN.
#12
Posted 29 September 2005 - 01:20 PM
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
Posted 29 September 2005 - 05:11 PM
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
Posted 29 September 2005 - 09:55 PM
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
Posted 29 September 2005 - 10:26 PM
I'd like to have a usefull CLSN
Do you understand what I mean ?
#16
Posted 30 September 2005 - 08:24 AM
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:
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.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
#17
Posted 30 September 2005 - 12:05 PM
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
Posted 30 September 2005 - 02:47 PM
Object 0/0...........0/m ........XXXXXXXXX XXXXXXXXXXXXXXX.. ..XXXXXX......... ...XXXXXXXX...... .....XXXXXXXX.... ...XXXXXXX....... n/0...........n/mShould'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/wBullet 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
Posted 30 September 2005 - 02:48 PM
How are you planning to do that on the AFX? =)We decided that there wil be a timer that can count time in 1/100 of a seciond
#20
Posted 30 September 2005 - 05:01 PM
#21
Posted 30 September 2005 - 05:30 PM
#22
Posted 30 September 2005 - 08:51 PM
#23 Guest_Guest_*
Posted 30 September 2005 - 09:57 PM
#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_*
Posted 30 September 2005 - 09:58 PM
#25
Posted 01 October 2005 - 08:32 AM
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
Posted 02 October 2005 - 04:15 AM
#27
Posted 06 October 2005 - 07:40 PM
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
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
Posted 07 October 2005 - 09:23 PM
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
#30
Posted 08 October 2005 - 08:46 PM
#31
Posted 16 October 2005 - 10:05 PM
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
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
Posted 18 October 2005 - 09:17 PM
#34
Posted 19 October 2005 - 05:31 PM
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
Posted 19 October 2005 - 07:57 PM
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
Posted 20 October 2005 - 06:45 PM
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
Posted 20 October 2005 - 07:24 PM
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
Posted 20 October 2005 - 08:02 PM
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
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...
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
Posted 21 October 2005 - 04:20 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users