"I'm thirsty" will be my entry for the Calculator Gaming Roots contest. I don't know if it'll be finished in time, but we'll see.
So basically there is a little boy who found a dragon egg in the countryside. The dragon born and is very hungry, so the little boy give him meat. Then, the little dragon is very thirsty, but the little boy can't make him drink since the dragon drinks kerosen. So instead he brings his dragon to a special laboratory, and scientists will take care of bringing kerosen to the dragon.
You are one of those scientists, and you must bring the liquid kerosen to the dragon through levels full of obstacles using the different objects of the level. The game will feature realistic water physics, among other things. Screenshots coming soon.
I've been working on another axiom for 3D, this time to work with 3D vectors (I planned more things) !
Just check the attached photos of a 32-sided solid sphere (no animated gif because no PC) knowing that I only draw lines (no filled triangles), and that it runs at approximately 6 FPS at 6 MHz on a TI-83+ non-SE
For now, all 3D rotation/projection is done in Axe, and the backface culling is done with the 3 current functions of the axiom, MakeVec(pt1,pt2,output), DotProd(vec1,vec2) and CrossProd(vec1,vec2,output). Source and binaries will come when I'll have a PC
WARNING ! HUGE AND BADLY TAKEN PHOTOS FROM A PHONE ! That's all I have atm.
I finally got something related with 3D working in ASM ! <this is a bit like a dream coming true for me >
Well, nothing too unbelievable, but I'm happy with what I have so far
So, I wrote 3 main routines, and a few other ones you can use, but these latter are not focused on 3D.
Main 3D routines :
BuildMatrix : builds the XY composite rotation matrix given the rotation angle about X and Y axis, respectively in b and c. The advantage is that you can rotate several vertices about the same angle without recalculating the rotation for each vertex.
ApplyMatrix : applies the matrix stored from AX to CZ (some .db in the program) to the three points stored at inX, inY and inZ and stores the result at outX, outY and outZ (more .dw). This is not necessarily a rotation matrix, but BuildMatrix writes to this area.
ProjectVertex : does the necessary calculation to project a vertex on-screen. Takes outX, outY and outZ as parameters and outputs at outX and outY. outZ remains unchanged.
Others routines provided (only because they are used by the 3 above routines) :
multHL_DE : performs HL*DE and stores the result in HL.
divHL64 : I let you guess.
mulHL64 : ↑ this.
AextendSignDE : converts the 8-bits signed number in A to a 16-bits signed number in DE.
getSin, getCos : retrieves the entry corresponding to the angle A in the trig look-up table (1-byte entries scaled to 64, so it goes from -64 to 64).
HLsignedDivDE : performs signed HL/DE, result in HL.
HLdivDE : performs unsigned HL/DE, result in HL (by Xeda112358).
Screenshot ? Yes, definitely :P
If you have any comment on the routines I described before I release the source, please tell me :)
To show my faith into Axe, I build a demo program in Axe. By "demo", I mean a program that shows what the language can do when pushed to its maximum
Well, I'm not saying I pushed Axe to its limit (ask Runer112 for that) but that I tried to write scenes that you don't see everywhere (in Axe at least)
The demo is named The Cutting Edge of Axe, is exactly 4088 bytes (not only executable, but also data) and contains 5 stunning scenes It's a Noshell program, so you can just run it with Asm(). Quickly press [enter] to go to the next scene. There isn't any command since it's a demo
So, I let you download it (attached, the executable is TCEOAXE.8xp and the source DEMO.8xp), and for those without a TI-8x+, screenshot in spoiler
Spoiler For If you have a TI-8x+, download the demo instead:
When you have to draw a great part of the screen pixel by pixel (like for a game of life), the program usually become reaaally slow, since Axe is not good at pixel drawing. So I've thought of a method to greatly speed up this kind of tasks.
So, how does it work ? You know that the TI-z80-s screen (excepted the 84+ C) takes 1 byte to code 8 pixels, so that 1 bit = 1 pixel. The technique consists in calculating each pixel as we would do normally, and then turn on or off the corresponding bit of a variable instead of turning it on on the screen (which is absolutely slower). Then, when the 8 bits of the variable have been modified the way you wanted, you can directly store the variable in the corresponding byte of the buffer, thus turning on/off 8 pixels at a time. Of course, this'll only work if the width of area you want to paint is a multiple of 8.
So let's do it !
Let's say that our function is named BuildByte, since that's what it does.
First, we need a counter. This counter must send a signal every 8 times we call it.
:.Only once :0→C : :Lbl BuildByte :If C++^8 :.The counter doesn't send the signal :Else :.It does :End :...
Then, we need the variable which will contain the pixels data : :.It must be initialized to 0 at the beginning of the program :0→B
Say that the function BuildByte takes three arguments, the X-coordinate of the byte where the pixel must be drawn (not the pixel, so it must be a number between 0 and 11), the Y-coordinate of the pixel (between 0 and 63), then 0 if the current pixel must be white, or 1 if it must be black. We need to put this 0 or 1 to the corresponding bit of B. Then if C is a multiple of 8, then it means that the 8 bits of B have been set, and we store B in the corresponding byte of L6.
But how do we do set the corresponding bit precisely, and not any other bit ? It's actually pretty simple : we always set the first bit, and then if C modulo 8 is not 0, we shift B left once. Why that ? After 7 shifts, the first pixel/bit you passed to the function will become the last bit → the first pixel of the byte when it's on-screen.
:Lbl BuildByte :.r1 is the X coordinate :;r2 is the Y coordinate :.r3 is the value of the pixel : :r3 or B→B :If C++^8 :B*2→B :Else :B→{r2*12+r1+L6} :0→B :End :Return
Remember that this will be efficient only if a relatively high number of calculations are needed for each pixel. For example, this plasma program I wrote a while ago uses this method (attached screenshot runs at 6 MHz).
This is something I wanted to do since ... a year or two but I never got it to understand and apply correctly the technique of raycasting.
BUT ! Now it's done
So I wrote this library which I named nRayC, because it's an Nspire lib about RAYcasting to be used in C
Although this library is mainly focused on raycasting, it's not its only use : I also included a bunch of functions, like pixel, line and even triangle (why not) drawing, tile detection, bitmaps loading and stuffs.
Currently, the library features raycasting rendered by a unique function :
It also provides two structures as you can see, ScreenPoint and Vector. I don't release anything for now because I don't think it's ready to be released, but I attach a screenshot of what it can do
I'm working actively on it, so expect progress every 2 days
In my free time I like to program some small animations on my calc, and I thought it could be cool to make a topic to show you the ones that I think should be shown
[Ndless C] Plasma (I know this already exists, but it doesn't use SDL anymore, for this I reused part of a library I'm writing to deal with screen and pixels). My library handles cross-compatibility, so you can use the same *.tns file for both CX and non-CX calcs
It takes ≈ 6 seconds to start because it has to compute and store 76800 * 7 sines and 76800 * 2 square roots in a table in order to get a decent execution speed
I've been working on ray casting since a little time and definitely can't make it work right. It's just crashing right now, and before crashing it did wrong maths.
I arranged the code like an engine (because that's want I'm wanting to do), so I can be sure that the problem is located in the nRC_rayCasting function.
int nRC_Cos(int angle) { // Beware ! All trigonometry is done in base 256 ! int table[256]={128,128,128,128,127,127,127,126,126,125,124,123,122,122,121,119,118,117,116,114,113,111,110,108,106,105,103,101,99,97,95,93,91,248,86,84,81,79,76,74,71,68,66,63,60,58,55,52,49,46,43,40,37,34,31,28,25,22,19,16,13,9,6,3,0,-3,-6,-9,-13,-16,-19,-22,-25,-28,-31,-34,-37,-40,-43,-46,-49,-52,-55,-58,-60,-63,-66,-68,-71,-74,-76,-79,-81,-84,-86,-248,-91,-93,-95,-97,-99,-101,-103,-105,-106,-108,-110,-111,-113,-114,-116,-117,-118,-119,-121,-122,-122,-123,-124,-125,-126,-126,-127,-127,-127,-128,-128,-128,-128,-128,-128,-128,-127,-127,-127,-126,-126,-125,-124,-123,-122,-122,-121,-119,-118,-117,-116,-114,-113,-111,-110,-108,-106,-105,-103,-101,-99,-97,-95,-93,-91,-248,-86,-84,-81,-79,-76,-74,-71,-68,-66,-63,-60,-58,-55,-52,-49,-46,-43,-40,-37,-34,-31,-28,-25,-22,-19,-16,-13,-9,-6,-3,0,3,6,9,13,16,19,22,25,28,31,34,37,40,43,46,49,52,55,58,60,63,66,68,71,74,76,79,81,84,86,248,91,93,95,97,99,101,103,105,106,108,110,111,113,114,116,117,118,119,121,122,122,123,124,125,126,126,127,127,127,128,128,128}; return table[angle & 0xff]; }
// ... // rotated is a 8 elements-large table of bunches of 3 values order = D3_sortFaces(rotated, (Vertex){0, 0, -150}, faces, 6, vpf); I don't know if you understand well, but I don't want to release a complete source for now
What this does is that it displays "0,0", \n then "Reset" and → crash.
If you have any idea of what's wrong, please tell me
Yesterday I got bored and wrote this small game in 30-40 minutes It's a 2 players minigame, so you'll need two calcs, a link cable and a friend.
You were engaged in an epic space battle against your greatest enemy when you see that your trajectories slowly brings you in an asteroid field ... which can change direction due to gravity perturbation.
So the point of it is that you must blast each other while dodging the other's shots and the asteroids that move on the screen. Your ship fires automatically and aims the other ship, so you only have to take care of avoiding being touched by anything. On the left side of each calc you can see a line that empties slowly ; when it's empty, the asteroid field starts moving in another random direction - so try to get away of any asteroid to avoid a sudden hit.
As I said, I coded this in less than an hour, so I didn't make any menu, nor even any automatic quit so basically, when the game stops, the player which has "Done" written on his calc loose, and the other win. If you win, press [clear] to exit the game.
Also, I only ask to one user to press [2nd] when the two are ready. So if you press without your friend ready, press [clear] and retry. To sum up, if something goes wrong, press [clear], I inserted a [clear] key detection in all loops of the game
The player who hits [2nd] first will be the empty square, and the other player the black square.
It's a pixel-based detection, so you can't say "meeeeeh this hitbox is bugged"
Spoiler For Badly taken huge photo:
Source (DUAL.8xp) and binaries (DUALSTAR.8xp) attached.
I'm in needs of sprites for IkarugaX, so by the way I thought that I could create (if it's not done already, please tell me if it's the case) a general sprite request topic, to avoid creating several ones for each game.
So, I need a 32*24 monochrome spaceship sprite, facing down. It's intended to be the first boss, so please make it look like a villain
Also, there's something to care about : the hit box has to be as large as possible, and obligatory rectangle-shaped.
Today I'm starting another project : Ikaruga X, a port of Ikaruga, this time in Axe !
For those who don't know what Ikaruga is, it's a danmaku (also bullet hell), a game where bullets are as numerous on screen as pixels. Here's an image which says, in my opinion, pretty well what Ikaruga is :
The goal is simple : reach the end of the level, while blasting everything you can see.
But it's easier said than done : bullets are everywhere, and you can't dodge them all. No, you can't. Don't try. I'm being literal. But your spaceship is a special spaceship : it has two "modes", black and white. So while you are in black mode, black bullets don't hurt you, and while you are in white mode, white bullets don't hurt you.
Planned features :
A lot of enemies. A LOT.
At least ten times as many bullets as enemies
MOAR WEAPONS
Epic boss battles
Various levels
And more, why not
For now, I've got the spaceship designed (tell me if you like it) and the shoot engine working for the very first weapon level.
I eventually thought of playing the game with your calc sideways, with the ship facing right instead of facing up. I think it'll be easier to play. Again, tell me your opinion about that.
I'm currently adapting F-Zero to use with the hoffa and t_k' mode7 engine, but I can't make it display a simple rotoscaled map. I didn't ask them because there's been a while they didn't even log in
So, I adapted a little bit the engine to make it work with non-square maps, but it keep not working.
if (isKeyPressed(KEY_NSPIRE_8)) m7AddVec(&pos, &moveDist); if (isKeyPressed(KEY_NSPIRE_2)) m7SubVec(&pos, &moveDist); if (isKeyPressed(KEY_NSPIRE_6)) m7AddVec(&pos, m7RotateVec(&moveDist, M7_INT_TO_FIX(1), 0)); if (isKeyPressed(KEY_NSPIRE_4)) m7SubVec(&pos, m7RotateVec(&moveDist, M7_INT_TO_FIX(1), 0)); if (isKeyPressed(KEY_NSPIRE_9)) heading -= 0x400; if (isKeyPressed(KEY_NSPIRE_7)) heading += 0x400; if (isKeyPressed(KEY_NSPIRE_ESC)) done = 1;
Show Posts
<this is a bit like a dream coming true for me 
>
