Bump,

Bazooka now destroys things ! That also means I now have a new mechanic to easily damage the map.



EDIT : no need to tell me about the damage-displaying bug, I noticed

<Hayleia> post it post it post it
<Hayleia> (then I'll tell you I never asked you to post it )

Hayleia forced me to post that (now you can't deny it ).

I wanted to see if I could still make a triangle filler with Axe. It appeared that I could, so I remembered that old 90's 83 demo saying "the first filled vector on calculators". So heh, here's another one. I also wanted to make an "old video recorder" effect on the screen.

So this will probably be a part of a demo, maybe yes, maybe no, we'll see.



As always, 6 MHz, not using Full, blablablah.

I guess it's because it's not the way the creator of Ion intended the Ion header. Try inputting an Ion header with an image with Asm( and see if it works.

Of course you can. In Axe, all expressions are numbers.

Okay so I've never done that before, but I gave it a quick think and that's what I thought of.

Let's say you have a curved surface sprite that is 16 pixels wide. Let's make it look like this :



Now you have to build a 16-entries normal angles table. By that I mean a table that will hold 16 values, one for each X coordinate on the sprite, and which will represent the normal angle of the pixel on that coordinate. I don't think you have to calculate them, just guess them based on what you see. Of course, they had to be in the range 0-255 and not 0-359.



Using these angles requires all of your velocities to use polar coordinates. That means that your ball will not have X, Y, VX and VY coordinates (VX and VY being velocity amount for X and Y coordinates), but X, Y, VR and VT coordinates. X and Y will be your ball's coordinates on the screen, like you always used them, but VR and VT will be the polar coordinate for your velocity vector - respectively the length and the angle.

When you hit a pixel - I'll let collisions to you - just grab the X coordinate of the pixel relative to the start of the sprite, get the corresponding angle in the normal angles table and apply symmetry with the velocity angle - I think you'd do velocityAngle += (pixelNormal - velocityAngle) * 2. Then that should be good.

Of course you will have to write the code to handle polar velocity. You might want to apply trig on the angle and multiply the result by the length, to add both results (X and Y) to the ball's coordinates.

That.

Looks like a very robust system ! I can't stop thinking of an OpenOffice-like program

Suggestions : would it be feasible to have different text sizes ? Embedded images ? Scrolling text for larger-than-screen document viewing ?