Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Matrefeytontias

Pages: 1 [2] 3 4 ... 7
16
ASM / So I wondered if Aether3D went unnoticed
« on: April 27, 2014, 08:16:43 pm »
So yeah. I was wandering in WikiTI's Experiments page, section 3D engine, and went trough different links to see which ones included source (you know, documentation and all). I had heard about qarnos's Aether3D but in some way I never got my hand on it or anything related to it.

Until I found an actual download. The zip doesn't contain the lib's source unfortunately, but the lib itself has been compiled into a flash app accessible via the same mecanism that I use with PageSwap (mapping the app to bank A and stuff). Taking a look at the readme (an amazing readme, you should see it), I realized how awesome it was, and how close to OpenGL it actually was O.O (scaled down to z80 calcs of course).

So it has pretty much anything one could expect from a 3D engine : rotations, camera handling, matrices, quaternions, model-loading automagic, arbitrary polygon-filling (any number of points), proper 3D clipping, all that stuff.

So I'm not doing it right now since it's 2:15 am, but I'm pretty sure it would be worth it to dive into it a bit (the zip includes an example and some models to play with), but I guess it'll be hard since the latest (understand : 2008) source is non-available.

Just pointing out.

17
ASM / [AXE/ASM] Improving a textured triangle routine
« on: March 31, 2014, 11:33:16 am »
Hey guys,

These last days I've been working on a textured triangle routine, mostly for the sake of having done one. For now it's Axe, I think it's rather well optimized (not too much) but it's still way too slow for my taste, so I thought of porting it to ASM.

So far I have this. It doesn't do any clipping on any side, so trying to draw out-screen will mess up your calc real good :

:E8000→°DX1+2→°DX2+2→°DX3+2→°X1+2→°X2+2→°DU1+2→°DU2+2→°DU3+2→°DV1+2→°DV2+2→°DV3+2→°DU+2→°DV+2→°U1+2→°U2+2→°V1+2→°V2+2→°SFlag+2→°SMid+2→°SEnd+2→°SX1+2→°SX2+2→°SU+2→°SV
:.Tri(°X1Y1,°X2Y2,°X3Y3,°U1V1,°U2V2,°U3V3)
:.Pic1 is a 16*16 image
:Lbl Tri
:Data(128,64,32,16,8,4,2)→GDB1MASK
:If {r1+1}>{r2+1}
:Exch(°r1,°r2,2
:Exch(°r3,°r4,2
:End
:If {r2+1}>{r3+1}
:Exch(°r2,°r3,2
:Exch(°r4,°r5,2
:End
:If {r1+1}>{r2+1}
:Exch(°r1,°r2,2
:Exch(°r3,°r4,2
:End
:
:{r2+1}-{r1+1}?,+1
:→Θ
:{r2}-{r1}*256//Θ→DX1
:{r5}-{r4}*256//Θ→DU1
:{r5+1}-{r4+1}*256//Θ→DV1
:
:{r3+1}-{r1+1}?,+1
:→Θ
:{r3}-{r1}*256//Θ→DX2
:{r6}-{r4}*256//Θ→DU2
:{r6+1}-{r4+1}*256//Θ→DV2
:
:{r3+1}-{r2+1}?,+1
:→Θ
:{r3}-{r2}*256//Θ→DX3
:{r6}-{r5}*256//Θ→DU3
:{r6+1}-{r5+1}*256//Θ→DV3
:
:DX2-DX1?,1.0
:→Θ
:DU2-DU1/*Θ→DU
:DV2-DV1/*Θ→DV
:0→SFlag
:
:{r1}*256→X1→X2
:{r1+1}→Y
:{r2+1}→SMid
:{r3+1}→SEnd
:{r4}*256→U1→U2
:{r4+1}*256→V1→V2
:
:If DX1-DX2/32768
:°X1+1→SX1
:°X2+1→SX2
:°U1→SU
:°V1→SV
:Else
:°X2+1→SX1
:°X1+1→SX2
:°U2→SU
:°V2→SV
:End
:
:While 1
:.Draw texture slice
:{SX1}→X
:{SX2}→Θ
:{SU}r→U
:{SV}r→V
:X and 7→r5
:X/2/2/2+(Y*12)+L6→r6
:!If r5
:Else!If -1
:{r6}
:./128
:Asm(3E80A5076F
:Else!If -1
:{r6}
:./64
:Asm(3EC0A507076F
:Else!If -1
:{r6}
:./32
:Asm(3EE0A50707076F
:Else!If -1
:nib{r6*2}
:Else!If -1
:{r6}
:./8
:Asm(CB3DCB3DCB3D
:Else!If -1
:{r6}
:./4
:Asm(CB3DCB3D
:Else!If -1
:{r6}
:./2
:Asm(CB3D
:End
:→r4
:While 1
:r4*2
:+({V/256*2+Pic1}rree(U/256))→r4
:!If r5+1 and 7→r5
:r4→{r6}
:r6++
:0→r4
:End
:DU+U→U
:DV+V→V
:EndIf X++>Θ
:r5?r4*{r5-1+GDB1MASK} or {r6}→{r6
:
:If SFlag
:DX3+X1→X1
:DU3+U1→U1
:DV3+V1→V1
:Else
:DX1+X1→X1
:DU1+U1→U1
:DV1+V1→V1
:End
:DX2+X2→X2
:DU2+U2→U2
:DV2+V2→V2
:Select(Y++,≥SMid?→SFlag)
:EndIf >SEnd
:Return


It does work, but it's reaaally slow (drawing 2 triangles is 6 FPS at 6 MHz) :



So before starting porting it to ASM (after I've got clipping working, but that is easy with the current code), I wanted to know if there was a better technique to do that. Basically, I'm doing it on a per-pixel logic (of course) but I interpolate every X and every Y, which I think is too slow.

Then I came around that 10-years old ASM scaled sprite routine by Badja and looking at the source and at how fast it was I felt like that technique could be used, although it can only shrink sprites. Basically, instead of interpolating every X, it calculates how many pixels has to be skipped and does the corresponding shifts according to it.

Would that be something feasible ? I didn't give it much thought by now, but seeing how slow my routine is, I'm pretty confident that there is a faster way. If it's not feasible in Axe but only ASM, it's fine, since I ultimately want to have an ASM textured triangle filler.

18
TI Z80 / Maybe that will become a demo
« on: March 16, 2014, 04:36:45 pm »
Quote
<Hayleia> post it post it post it
<Hayleia> (then I'll tell you I never asked you to post it :P)

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

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.

19
Miscellaneous / Metaphore about programming
« on: March 03, 2014, 06:12:36 pm »
So I thought of that today.

Let's say a computer program is a mountain. To finish writing the program, we must reach the top of the mountain. There are several treasures hidden everywhere in the mountain, those are optimizations. In order to make it we have different means of transportation, the programming languages.

For example, Python is a good car. It can go fairly fast and reach the top rather quickly, but you will miss a lot of treasures going that fast.

C is like a good bike. It can go nearly everywhere. Nearly. It will take a lot more time to get to the top, but you'll find many more treasures on your way if you look well.

And then ASM is your good old feet. You will take forever to get to the top, but you can really go anywhere and find each and every treasure of the mountain. It takes ages, but the result is usually worth it.

But there's more than that. There are an infinite number of mountains, but they usually share common tracks. So for example, you can get off your bike and do a small part of the travel by feet - inline ASM -, but you can't get out and push the car.

Also, habits apply here too. If you feel like you're familiar enough with a part of the track, you can attempt doing it walking instead of riding a bike. However, you usually will stay in the bike path and just grab some treasure you see from the road, not seeing that there are ways you couldn't take on your bike that you can now follow by feet, and thus you miss many treasures.

So yeah. Thought of that today.

20
Axe / [Axe] Plane deformations are fun
« on: January 23, 2014, 01:02:36 pm »
Hey guys,

Graphically impressive (read : useless) programs had always been my thing, so when I figured out that I could do some intense LUT-based demoscenes-like programs (my first one was actually nSpeedX3D, it uses the same concept), I took the only programmable machine that was near me : my TI-83+. Could have been my PC, but I was at school.

So, in a mere 3 hours I wrote a small LUT generator that takes X, Y as input (the center of the screen being 0,0) and gives U, V as output. Basically, X and Y are screen coordinates, and U and V are texture coordinates, so I use those to draw things on the screen with a bit-per-bit basis - very slow in Axe, but w/e, it was meant only to look good, not to be fast. Actually, you can argue a bit about it looking good, but I couldn't really do any better with Axe's precision and the z80 calcs' LCD.

So yeah, basically, to perform a plane deformation, you don't need many things :
  • A texture (I use a 8*8 one),
  • Two 6144-bytes LUTs (yup, that's a lot), one byte for the X of each pixel, one byte for the Y,
  • Two equations, one that gives U, one that gives V.
So first, you want to make sure everything works. So you just do U = X and V = Y. It gives this.



(Note how the LUT generation takes ages. We actually generate 12288 coordinates.)
Now that you're certain it works, you can start doing actually funny and interesting things ;D

r = sqrt(x² + y²)
a = tan-1(x,y)


u = x * 8 // abs(y)
v = 512 / abs(y)



u = x * cos(r * 2) - (y * sin(r * 2)) // 256
v = y * cos(r * 2) + (x * sin(r * 2)) // 256



u = 1.0 /* (r * 256 + 0.5 + (sin(a * 5) // 2))
v = a * 3 * 256 /* 3.142



u = r * cos(a + r) // 320
v = r * sin(a + r) // 320



u = a
v = 1.0 /* r



Also, the whole program includes those 5 scenes and is only 1354 bytes. So it can be done very lightly.

To use it, just put a number between 0 and 5 inclusive in Ans before running Asm(prgmPLDEFORM). You need at least 13800 bytes of free RAM though. No test is done to see if Ans is out of bounds, but that shouldn't do anything else than displaying random garbage. Binaries attached, source will come later (when cleaned).

I'm going to make everything more ergonomic and release it as a pure eye-candy program I guess (among with some additional equations).

21
TI Z80 / [Axe] Free bitmapper/pixelmapper/smoothscroller for everyone
« on: January 08, 2014, 05:56:06 pm »
Hey guys,

As it turns out the bitmapper I wrote for Worms was respectabily fast, I thought that some people would like to use it for their projects. It has ASM in it, so be sure you copy it correctly.

So first, here's the actual code. Sorry to not provide an 8xp file, but I'm posting from my phone as I have no PC for a while :/ instructions on how to use it are below it.

:~1
:For(64)
:+1
:Asm(E5)
:Copy(->r1+CamY* MapW + (CamX/2/2/2)+ MapPtr, r1*12+L6, 12)
:Asm(E1)
:End
:
:If CamX^8
:->r3
:For(r3)r
:Horizontal-
:End
:
:~1
:For(64)
:Select(+1,{->r1+CamY* MapW +(CamX/2/2/2+12)+ MapPtr} and (e^(8-r3->r4)-1 xor EFF)Asm(5D)r4Asm(45CB3B10FC6B) or {r1+1*12-1+L6->r2}->{r2})
:End
:End


At least it's more understandable than Runer's code.

So yeah, don't worry, I had a hard time copying it here too :P

How to use that thing :
  • MapW is the width of your map in bytes. It can be any unsigned 16-bit number.
  • CamX and CamY are the coordinates in pixels of the top-left pixel displayed on the screen. You'll have to make sure yourself that they won't go over MapW-96 for the former and MapH-64 for the latter.
  • MapPtr is simply a pointer to your MapW*MapH map.
  • Just to make sure, ~ is the negative sign, not to confuse with the minus sign.

Just copy-paste that bunch of code at the place in your program where drawing occurs, and since the whole screen is covered with the map, you don't need ClrDraw anymore, and don't need to maintain the map in an external buffer either. Just keep your plain map for the engine, no need to modify it for scrolling.

If you use that code in your program, it'd be cool to give me credits just for it :)

I can't really know how fast it is, since a whole physics engine runs on top of it in Worms (but it's still fast, so I thought it would be worth posting). So, since I have no PC, could someone post speed tests and/or screenshots, to see how fast it is ? Kinda like Runer did for his own bitmapper one year ago :P

Share your comments :)

22
Calculator C / [Ndless] Interrupts newbie here
« on: January 05, 2014, 01:19:43 pm »
Hey guys,

I want to make, like, the simplest interrupt ever : increment a variable if the second timer (0x900D0000) reaches zero.

About interrupts, I already know ... nothing. I'd need something like :

Code: [Select]
attachInterrupt(0x900D0000, incrementTimer);
...

void incrementTimer(void)
{
  timing++;
}

Can anyone help me with that ?

23
Hey guys,

So, basically, what the title + subtitle says. I just thought it was cool to have a game with a fully-rendered 3D tunnel in it. I have the tunnel, now if you have ideas of a game to put it in, please let me know. ;D



It's pure Axe (excepting some Asm(CB3D) to fasten /2), exactly 2000 bytes, the way it's coded allows for custom deformation of the tunnel (for now, each segment has X = cos(timer), Y = sin(timer)), it's endless, it runs at 9 FPS at 6 MHz and it doesn't use GLib.

Any idea to share ?

EDIT : Frostion suggested http://armorgames.com/play/10289/vector-rush .

24
TI Z80 / [Axe] Worms - name subject to changes
« on: December 18, 2013, 07:42:24 am »
FOR LATEST UPDATES, SEE LAST PAGES !

Hey guys,

After IkarugaX, it's time for me and my team (we three together make the "RMV Pixel Engineers" team) to work on another project :)

This time we chose to port a game (again) that the three of us wanted to see on a TI-83+/84+ one day, but couldn't find any version that was complete, fast and playable while remaining good-looking : Worms, by the almighty Team 17 !

I know there were several attempts to an ASM Worms, including TI-ny Worms a decade ago and Kindermoumoute and Hayleia' Axe Worms one to two years ago, but they both died, so yeah.

We started the project three weeks ago, so we had time to get several things working. You can also follow us as we progress on the game by regularly checking our site, which is basically a single web page where we put articles.

Latest screenshot (10/05/2014) :



Share comments :)

25
Math and Science / Best way to use quaternions ?
« on: December 08, 2013, 08:33:23 am »
Hey guys,

I've recently got some interest for quaternions, since I couldn't take Gimbal Lock anymore. So what I did is write a small quaternion lib in Axe, but realized I could do at max 15 FPS, where with a classical 3*3 XY rotation matrix I could do more than 56 FPS. So I was asking myself, what's the best way (by that understand : the fastest, the one that uses the less calculations) to use quaternions ?

Right now I use this technique :
  • Start with an identity quaternion and its conjugate.
  • Game loop :
    • Multiply each vertex by the quaternion and its opposite : v' = q * v * q-1
    • If an arrow key is pressed, multiply the quaternion by another quaternion representing the correct rotation : if left arrow is pressed, multiply by a quaternion traducing -4° around the (0,1,0) axis, if it's the up arrow multiply it by a quaternion traducing 4° around the (1,0,0) axis etc. I build a quaternion out of an axis and an angle : q = sin(Θ/2) * axis + cos(Θ/2)
    • After that, get the conjugate of the resulting quaternion.
    • Get back to the beginning.
I'm not quite sure this is the best way to do it since multiplying two quaternions implies 16 multiplications, and rotating a vertex by a quaternion implies 2 quaternions multiplications. Any idea ?

26
Other Calculators / IkarugaX z80 danmaku / shoot-them-up
« on: November 30, 2013, 09:25:16 am »
IkarugaX z80 danmaku / shoot-them-up

Alright, time to upload IkarugaX to Omnimaga's archive. After all, the project is born here.

http://www.omnimaga.org/index.php?action=downloads;sa=view;down=873

27
Axe / Approximating inverse trigonometric functions
« on: November 21, 2013, 07:43:26 am »
Hey guys,

I wanted to use cos-1 for a spherical mapping, but since it doesn't exist in Axe, I had to approximate it :P

So here's the thing : cos-1 =

Okay I'll explain that ;D

So I did it in a non-fonctionnal way, thus with an algorithm. Basically, it takes a parameter in the range [-128,128] and returns the corresponding cos/sin -compatible angle (between 0 and 256 inclusive).
  • First, if |x| is lesser than 89 (I took that value from a graphed cos-1) :
  • Else :
  • If x > 0, we substract the result from 128.
And amazingly, that gives us an approximation with an error range of only 1 ! :D

If someone could graph the thing, Wolfram doesn't seem to be capable of that.

So here's the Axe code as I did it :

:Lbl ArcCos
:~abs(r1)→r2
:If r2>>~89
:~r2//3+64
:Else
:128-sqrt(r2+128*30)
:End
:→r2
:r1ee0??128-r2→r2
:r2
:Return


Exactly 255 bytes in Noshell, isn't that beautiful ;D

I'm working on sin-1 as well, so expect it for in a few hours.

28
TI Z80 / [Axe] Dynamic 3D functions explorer thingy
« on: November 14, 2013, 01:34:43 pm »
Hey guys,

Seeing the challenge TheMachine02 shamelessly sent me (:P), I wanted to try and do some 3D, but this time without defining any vertex by advance. So this came out.

What it features :
  • 3D graphing of any function that only involves integer maths (8.8 maths are coming, maybe) on the [-6,6] range (13*9 = 117 dots)
  • Dynamic movement around the graphed function : translation, rotation around the Y axis and zooming in/out
  • Dots and grid view
  • Clipped line routine ! :D
  • Support for animated functions. More on that below
  • All of that in less than 2400 bytes of pure Axe !

So yeah, it's not really useful, but I found that it would be cool to try and do such program.

Small precision : the graphed function doesn't give exact results. I mean, there's no such thing as units. The only point of that is making good-looking results on-screen, it's not a mathematics tool.

How to use it : by default, prgmDOTSURF (Noshell executable) will graph the 2x² function. You can move around the graphed function with the arrows, zoom in with + and out with -, rotate left with [Y=] and rotate right with [graph], switch between dots and grid view with [mode] and exit with [clear].

You can also define your own function for the program to graph. To do that, just edit prgmFUNC3D. While I'm speaking about a "function", this is actually Axe code that you'll have to compile. I want to make this into a more user-friendly way, but I still have to figure how. Here're instructions on how you can define your function :
  • The graphed function is f(x,z) = y. X and Z of the current point are passed respectively in r2 and r3, from -6 to 6 and -4 to 4 respectively. You are free to use these, but they must remain the same value at the beginning and the end of your function. They are used for the drawing code. Also, store the resulting Y coordinate into r6. Do not use Return.
  • You cannot edit any of the following variables, meaning that they must have the same value before and after your function : r2, r3, r4, A, B, C, D, E, F, H, V, Y, Z, ?. Also, you can't use any of the bytes from L1 to L1+702, nor the 256 first bytes of L3.
  • If you want to use trig, do not use Axe's sin/cos functions, but type Sin() and Cos() instead. Those are way faster, LUT-based routines that I made. Remember that this will destroy r1, unless you call it with sub(Sin) or sub(Cos) and writing the value right before it. Those functions still returns the same output as Axe's ones. Also, Y holds the current Y rotation angle.
  • You can write animated functions : the O variable is a timer that gets incremented by 16 every frame. You are free to use it.

Remember that grid mode will lag a lot at 6MHz, since the program has to draw a line between each of the 117 dots.

So, I think that's all. For those who don't know Axe but want to try anyway, I give you some functions that you can copy in prgmFUNC3D (that will also be an example for those who want to write their own :) ) :

The default 2x² :
r2*r2*2?r6

One of my favourite functions (also, one that demonstrates well the clipped line routine), the good old x3 :
r2*r2*r2?r6

Some animated sinusoidal function :
Sin(r2*16+O)//4?r6

More animated sinusoidal function to demonstrate the use of both X and Z coordinates to generate Y :
Sin(r2*16+O)+Cos(r3*16+O)//4?r6

Here's a little screenshot that describes the process of drawing 2x² and navigating around the graphed function (at 6MHz of course) :



Don't be horrified by the how-so non-user-friendly interface, I'm working on it :P

prgmFUNC3D is the program you have to edit to write your own function, prgmSINE3D is the source to compile, and prgmDOTSURF is the executable (here, it contains the 2x² default function).

Feel free to make functions, share them with others if you want, and don't hesitate to ask if you have questions :)

29
TI Z80 / [Axe] Faces, a 3D space shooter
« on: October 28, 2013, 09:38:13 am »
Hey guys,

I've been reluctant about making a thread for this as I wanted it to be my secret project, but tifreak convinced me, so here it is :P

Faces is a 3D space shooter taking place in a distant (and much unlikely to happen) future where a rebel armada took over many planets of the universe to do rebellion-related stuffs. Your mission, as an agent sent by the official government, is to free these planets by destroying the turrets the rebellion put on them.

The game is far from finished and not really enjoyable as the enemies don't have sprites, don't fire and die with one shot, I have only one planet (although the level format/loading is working) among other things.

BUT ! All the 3D rendering is done, XY rotations are working, planets are solid, I have a beautiful stars background, 3D collisions between your laser and the faces of the planet and the enemies are done, score with custom font is working (thanks Keoni29 from Omnimaga for the font), everything running at 20 FPS at 6 MHz on my TI-83+.fr. :D

So, let's have a little screenshot, shall we ?



I don't post a demo for now because I don't think it's really worth it, but if you want to try anyway with the few things you can do with it, just ask and I'll post it :P

Share comments :)

30
Axe / Write the fastest 3D cube
« on: October 27, 2013, 04:10:55 pm »
Hey guys,

With TheMachine02 we made a contest about who could write the fastest 3D cube, me vs GLib ;D The rules are simple :
  • XY rotation
  • The cube must be made out of 8 dots that are always visible
  • Each dot appears on-screen as a 2*2 square
  • No ASM code, only pure Axe
  • 6 MHz only
My program reaches 56 FPS (when not moving, and 54 FPS when moving) while respecting all these conditions. I'm pretty proud ;D



And here's the source :

Quote from: Axe
:.FASTCUBE
:#ExprOn
:FnOff
:Data(‾40r,40r,‾40r)°Verts
:Data(40r,40r,‾40r)
:Data(40r,‾40r,‾40r)
:Data(‾40r,‾40r,‾40r)
:Data(‾40r,40r,40r)
:Data(40r,40r,40r)
:Data(40r,‾40r,40r)
:Data(‾40r,‾40r,40r)
:
:Buff(6)°Back
:
:L3°CosLUT
:
:L3+512°CosX+2°CosY+2°SinX+2°SinY+2°CXCY+2°CXSY+2°SXCY+2°SXSY
:
:1
:For(256)
:Select(+1,cos(r1){r1*2+°CosLUT}r)
:End
:
:0XY
:
:While 1
:Sin(X)SinX
:Cos(Y)CosY
:Sin(Y)SinY
:*SinX//128SXSY
:Cos(X)CosX*CosY//128CXCY
:‾CosX*SinY//128CXSY
:CosY*SinX//128SXCY
:
:°Verts-6
:For(8)
:{+6r2}r*CosY+(SinY*{r2+4}r)//128{°Back}r
:SXSY*{r2}r+(CosX*{r2+2}r)-(SXCY*{r2+4}r)//128{°Back+2}r
:CXSY*{r2}r+(SinX*{r2+2}r)+(CXCY*{r2+4}r)//128+192{°Back+4}r
:
:Rect({°Back}r*64//{°Back+4}r+48,{°Back+2}r*64//{°Back+4}r+32,2,)
:r2
:End
:
:DispGraphClrDraw
:getKey(3)-getKey(2)*4+YY
:getKey(4)-getKey(1)*4+XX
:EndIf getKey(15)
:Return
:
:Lbl Sin
:-64
:Lbl Cos
:{^256*2+°CosLUT}r


Generated by the BBify'r (http://clrhome.org/bbify/)

If you want to try, please do :P

Pages: 1 [2] 3 4 ... 7