I'm still waiting for mutliplayer linking, so I voted that way again. I expect that more people will want sprite rotation though. =)

same with me, builderboy. two more features i can add to my tilemapping program (:

What about USB support.  I know it would be difficult, but could you do it?

@graphmastur: Pretty sneaky. Did you get any ideas for the calc side of things (assuming you know Z80 asm)?

@Quigbo: Oh yes, that's definitely a must. (nemo's idea)
That shouldn't be too hard to implement.

Well I didn't find it that rude, and its nice to see some criticism for a change, I was getting worried 

There are a few technical considerations because its not as simple as a number substitution since the labels aren't actually well defined until the end of the first pass, so its a little more difficult.  That also means the "label values" start using up the available space for label names (there is a 150 name limit for labels).  Secondly, just getting the value of the label is not very useful unless you can actually jump or call to that address.  I'd like to see you propose an intuitive syntax for that since I can't think of a good one off the top of my head.  Lastly, it allows for arbitrary execution of assembly code which is against the rules of the contest if that's what you were planning to use it for.

I was just trying to make my opinion clear, not offend anyone.  Of course it is Quigibo's project, I just thought it would be cool and would open the doors to more advanced things.  This would be useful for a GUI engine, a physics engine, lots of different engines , and I can think of a practical application being using the Hatchet routines loaded in L1 (the code in L1 is pure Axe, by the way).  Hatchet could also use the label values to actually load the code.  It might be useful to programs to use my tilemapping routines and input routines, and all the other routines Hatchet would provide and still be valid for the contest.
As for a possible syntax, how about accessing label values with _LLABELNAME (sort of like _EHEX) and doing arbitrary calls with sub()^r?

not sure if this is a relatively simple command, but could we have a Prompt/Input function? just like in BASIC, you have the user enter a number and it's stored to a program-specified variable.

There are a few routines that do this already, I can scrounge one up for you later today.

I just want to be clear about how sprite rotation and flipping will work because I don't want people thinking its something that its not.  The commands take 1 argument; the pointer to the 8x8 sprite and the return argument is a pointer to an 8 byte buffer in an unused safe ram area outside of L₁-L₆.  This area holds a copy of the "new" sprite after the transformation.

Pt-On(X,Y,FlipH(Pic1))
I was originally thinking of having a second argument allowing you to specify what area of ram to use as the temporary buffer, but then I realized that it would be easier to use, smaller faster code, and take up no extra visible memory with the single argument instead.  The only problem though is that you cannot  nest these routines together, maybe with an exception of the flip horizontal.  Like for instance RotCC(FlipV(Str1)) will fail because the input and output buffer are the same.  Therefore, I might still have the second argument, but it would be optional.

Also, the subroutines themselves that do the flipping are around 2 sprites in size and it costs an extra 3 bytes each time you call them and is obviously slower than just using a regular pointer so you'd have to be really desperate for space with massive amounts of sprites to even consider using this.

is the following code valid?

Code: [Select]

Copy(FlipH(L1),L1,8)


Yes, absolutely.  Although this is theoretical syntax.  I haven't even chosen tokens or names or even finished most of the routines.

I voted sprite rotation/flipping, because most other people chose that . Also, it might come in handy when you make a game that requires rotating of an object (like a ship).

Besides, multiplayer linking is only useful when you have two people, so it can wait until a later version release.