Is axe fusion allowed? If so, I've got 264 bytes. Otherwise, I have 416 bytes and have to find an other way of doing this.
BTW: Does ^64 compile to " and %0000000000111111" ? (and being the 16-bit and instruction (plot style dot),and % being the pi character) Both have the same size when compiled.
I have created a simple example program to show how you can use GLib in a game. It handles basic wireframe rendering, as you can learn from the tutorials, but it also shows you how to make a dynamic level, a way to use very large levels without getting accuracy problems, and a way to move the camera in an other way than by GLib's GGetKey() function.
This is a screenshot of how it looks:
You can find the partially commented 8xp file in the attachement. The full source code in ASCII format with more comments can be found in the spoiler below.
Spoiler For "Source code":
.TUNNEL3D
.INCLUDE GLIB prgmGCORE
.Add a world view camera, and set the coordinates to (0,0,0) GNewCam(^^oGWORLDVIEW) 0->GCPosX->GCPosY->GCPosZ
.Set up the vertex buffers. VBuff is for the world space vertices, VBuff2 is for the screen space (transformed) vertices L2->^^oVBuff->GVAdr L3->^^oVBuff2->GVStr
.The sprites for the player and their masks [0000007E997E0000]->GDB1 [00007EFFFFFF7E00] [00183C7E997E0000] [183C7EFFFFFF7E00] [00007EFFFFFF7E3C] [0000007EFF7E3C18] [00003E2E1E0A0600] [003E7F7F3F1F0F06] [00007C7478506000] [007CFEFEFCF8F060]
.Generate a straight tunnel in which the player will start ^^oVBuff->A 5->B For(15) ~20->{A}^^r B->{A+2}^^r ~20->{A+4}^^r
20->{A+6}^^r B->{A+8}^^r ~20->{A+10}^^r
20->{A+12}^^r B->{A+14}^^r 20->{A+16}^^r
~20->{A+18}^^r B->{A+20}^^r 20->{A+22}^^r
A+24->A B+10->B End
.Set up the variables .Used for the level generator: F and G represent the X and Y coordinates of the center of the last tunnel frame .J and K represent the angle of the tunnel segment that needs to be generated .H and I are counters used to determine the length of the tunnel piece being generated (because of this, the tunnel is a series of bents instead of randomly displaced squares 0->F->J 0->G->K 0->H 0->I .S is the score (number of frames since the start of the game) 0->S
.SETUP OTHER STUFF (makes the text being drawn on the buffer, and inverted) Fix 3 Fix 5
.MAIN GAME LOOP Repeat getKey(15)
.MOVE THE CHARACTER .The +3 is the speed of the player in the Y-direction. GCPosY+3->GCPosY .If the character's Y-position is greater than 10, then the world has to be moved backwards by 10 units (this way, the player never gets away too far from the orgin, so that there won't be problems with overflows) If GCPosY>10 GCPosY-10->GCPosY .SHIFT WORLD Copy(^^oVBuff+24,^^oVBuff,336) ^^oVBuff+2->A For(60) {A}^^r-10->{A}^^r A+6->A End
.Generate a new tunnel piece. This is done by adding random offsets to the center of the squares, but it adds the same offset multiple times to make it look more like a neat tunnel instead of a random mess.
If H=0 rand^17-8->J rand^(20-abs(J))+1->H End If I=0 rand^17-8->K rand^(20-abs(K))+1->I End
.CONTROLS: move the player based on what kays are pressed. The *2 determines the speed at which the player can move in the XZ plane getKey(3)-getKey(2)*2+GCPosX->GCPosX getKey(4)-getKey(1)*2+GCPosZ->GCPosZ
.CHECK IF PLAYER DIED
GCPosX->A GCPosZ->B ^^oVBuff+48->C
If {C}^^r+2>>A or ({C+4}^^r+2>>B) or ({C+12}^^r-2<<A) or ({C+16}^^r-2<<B) .If the player is within 2 units from an edge of the third frame, then the player died and the program is terminated (we use the third frame because the camera appears behind the player) Goto END End
.TRANSFORM THE VERTICES (This basically does the same as the tutorial) ^^oVBuff->A ^^oVBuff2->B For(60) GVertex({A}^^r,{A+4}^^r,{A+2}^^r) Copy(^^oGVertex,B,6) A+6->A B+6->B End
.DRAW THE TUNNEL ClrDraw .Because the tunnel consists of simple squares, the vertices can be connected by a very simple algorithm, so that we don't need to read them from a link list 0->E For(15) For(3) GClipLine(E,E+1) E++ End GClipLine(E,E-3) E++ End
.Draw the score Text(0,0,S>Dec) S++
.Draw the correct player sprite, based on the keys being pressed If getKey(3) Pt-Mask(44,28,GDB1+48)^^r ElseIf getKey(2) Pt-Mask(44,28,GDB1+64)^^r ElseIf getKey(1) Pt-Mask(44,28,GDB1+32)^^r ElseIf getKey(4) Pt-Mask(44,28,GDB1+16)^^r Else Pt-Mask(44,28,GDB1)^^r End
The code makes a loop that updates every time the getTime is displayed,this only shows for about 20-30 seconds and to exit it press the on button.
For loops should be closed by an end. Goto can be used to form a loop, but using a goto to go out of a loop is usually a bad idea. iirc it can even cause a memory leak.
:For(<variable>,<start>,<end>) :<do something> :End<variable> is a real variable (=uppercase character or one of the variables from the finance app). At the start of the loop, that variable is set to the <start> value. Then, the code inside the loop is executed. If the variable is smaller than the <end> value, it gets incremented (1 is added to it), and the code in the loop is executed again. This keeps happening untill the variable is greater than or equal to the <end> value.
An other thing that seems slightely inaccurate is that you say in the title that it works on any ti calculator. This is most lickely not true. The lay-out of this code looks like basic for the z80 line (83+/84+ lines), and not all calculators in that line have a clock, so GetTime won't work on all of those calculators (iirc only on the 84+ line (84+, 84+SE and probably also the 84+CSE)).
Anyway, if anything is unclear, feel free to ask about it. This forum has a lot of helpfull members.
Could you tell us a bit more abouth this project? Like what kind of game you're making, platform, etc. It is also not fully clear if you want those sprites in b&w, greyscale or color.
(by the way, I was wondering ben_g, do you think we can do only one division per triangle ? cause right now I do one division by scanline)
I only did the divisions for the top 2 scanlines. The intervals that have to be added to the u and v coordinates are constant for every scanline (as long as you use affine texture mapping, instaed of persfective corrected texture mapping), so you can just re-use the results from them for every other scanline. Oh, and the reason that I use the results from the 2nd scanline is that the first scanline is very short (often only 1 pixel), so the intervals calculated in it are often inaccurate.
If you want to rotate it by 90° turns, rotating the tilemap is quite easy: you just add a modified subroutine to acces the tiles with the x and y coordinates swapped. And if the result is mirrored, substract one of the coordinates from 15.
To rotate the sprites themselves, it may be a bit harder, but since 4*4 sprites don't take up much space, it might be best to just save the rotated sprites as well. Just add them right after the normal tiles, in the same order (so they are at a fixed offset to the normal tiles). Then, to acces the rotated sprites, just add that offset to the pointer of the normal sprite.
If you want to rotate the tilemap by a certain amount of degrees, it will be a lot more complicated, and I don't know exactely how it should be done.
This is how I think of it: 0.9 = 1 - 1/10 so with 1 digit behind the comma, it is 1/10th less than 1 0.99 = 1 - 1/100 so with 2 digits behind the comma, it's 1/100th less than 1 0.99 ... 9 (n digits behind the comma) = 1 - 1/(10^n) and for infinity: 0.99... (∞ digits behind the comma) = 1 - 1/∞, and anything divided by infinity (except for infinity itself) is 0, so it equals 1-0=1.
some test with the pxl and the geometry shader. The first screen, I only pass one primitive (only one quad) as argument, the shader create a new piece of geometry from the one already there.
+-20fps
If you'd deform the reflection by a sine or such, you could make a water shader of this.
What might be useful is to instead gray the cursor so that the point is more visible. Right now the cursor covers the point and makes it difficult to tell exactly where it is, especially at higher depths relative to the camera. If you had a way to gray out the cursor and draw the selected point over it in black then the point might be much easier to see.
graying out the cursor is done in the grayscale version, so do you want a combination of the two where the vertices stay black but the cursor is gray?
When I add line drawing or selecting multiple vertices, would you prefer the points to stay black and the selection being indicated by multiple gray cursors? Or add gray cursors to the selected points, maybe with the real cursor being black, or do you prefer to have it all in b&w?
It's a bit too early to do that, because it now only supports points.
I did add a new feature, though: it can now also delete points (I kinda forgot this).
Further, I have decided to release the source code for this program, in case someone wants to learn from it (attached to this post, compile with the latest version of GLIB and axe).
PS: It would be nice too see more votes in the poll, so I know on what I should base the line drawing interface. (which will require you to select two points and it'll add a line inbetween)