This makes me wonder about sprites.
My concern are math operations, though. On the 39gII, maths, especially floating points calculations, were particularly slow compared to graphical display. In the Prime emu, if I use decimals I see a noticeable slowdown when I do complex animations and stuff.
You might even need to slow down your games with some loops! :POn the computer software, it seems as if there is a WAIT() command to wait a certain number of seconds, and it works with fractions of seconds. there is also TICKS for the overall system clock in milliseconds, which could be used to make timing or scoring more accurate/precise/cool.
thanks, I'll try that code later. As for decimals, I mean that in the emulator, I noticed that stuff like A+1.1 is noticeably slower than A+1. I'll have to give that another try when i get home on my comp.This makes me wonder about sprites.
Something like this should work... haven't tested it. Scales it up too.
EXPORT Sprite()
BEGIN
DIMGROB_P(G2,4,4,{ #7C0003E0001F0000:64, #0, #0, #7C0003E0001F0000:64 });
BLIT_P(G0,20,20,100,100,G2,RGB(0,0,0));
WAIT(3);
END;QuoteMy concern are math operations, though. On the 39gII, maths, especially floating points calculations, were particularly slow compared to graphical display. In the Prime emu, if I use decimals I see a noticeable slowdown when I do complex animations and stuff.
Please elaborate. Basically, in the non-CAS programming there is absolutely no difference internally between 1 1.0, 1.1 or 1.1111111111. They are all the same thing.
TW
thanks, I'll try that code later. As for decimals, I mean that in the emulator, I noticed that stuff like A+1.1 is noticeably slower than A+1. I'll have to give that another try when i get home on my comp.It might be that the C++ compiler is able to optimize Ints and Integers more than Floats and Doubles on the computer, yet on the calculator they are just as fast.
It might be that the C++ compiler is able to optimize Ints and Integers more than Floats and Doubles on the computer, yet on the calculator they are just as fast.
@critor: Question: Is the LCD refresh rate capped at a certain framerate like on the 39gII (which was 10 FPS)?
All numbers in the numerical part of the system (ie not in the CAS) are BCD encoded.Good. Though using BCD floats is usually slower than using binary floats is, BCD floats have at least one advantage: 2.0 + 1.0 = 3.0, instead of, say, 2.0 + 1.0 = 2.9999999999999999 with binary floats. Arbitrary shifts and rotates in the ARM ISA probably helps reducing the performance gap between BCD and binary floats.
EXPORT Sprite()
BEGIN
FOR Z FROM 0 TO 239 DO
RECT_P(G0,304,Z,319,Z+1,RGB(INT(RANDOM(256)),Z,240-Z));
END;
WHILE 1 DO
FOR X FROM 0 TO 18 DO
FOR Y FROM 0 TO 14 DO
16*INT(RANDOM(14))->V;
BLIT_P(G0,16*X,16*Y,G0,304,V,320,V+16);
END;
END;
END;
END;EXPORT spritetest2()
BEGIN
DIMGROB_P(G1,120,48,RGB(0,0,0));
TEXTOUT_P("HELLO",G1,0,0,7);
FOR Z FROM 1 TO 800 DO
RECT_P(RGB(Z/4,Z/4,255));
BLIT_P(G0,0,0,Z,Z,G1,RGB(80,255,255));
WAIT(0.03);
END;
END;
EXPORT scrollingtest()
BEGIN
DIMGROB_P(G1,800,800);
FOR Z FROM 0 TO 800 DO
RECT_P(G1,0,Z,800,Z+1,RGB(INT(RANDOM(125)),INT(Z/7),0));
END;
FOR Z FROM 0 TO 800 STEP 4 DO
RECT_P(G1,Z,0,Z+1,800,RGB(INT(Z/6),INT(RANDOM(156)),INT(RANDOM(156))));
END;
0▶X;
0▶Y;
1▶Z;
WHILE 1 DO
Y-(ISKEYDOWN(2))+(ISKEYDOWN(12))▶Y;
X-(ISKEYDOWN(7))+(ISKEYDOWN(8))▶X;
Z-(0.1*ISKEYDOWN(45))+(0.1*ISKEYDOWN(50))▶Z;
BLIT_P(G0,0,0,INT(320/Z),INT(240/Z),G1,X,Y,320+X,240+Y);
WAIT(0.02);
END;
END;
EXPORT Sprite()
BEGIN
DIMGROB_P(G2,4,4,{ #7C0003E0001F0000:64, #0, #0, #7C0003E0001F0000:64 });
BLIT_P(G0,20,20,100,100,G2,RGB(0,0,0));
WAIT(3);
END;
By the way, is there any image<>hex converter that supports A1R5G5B5 format or something that can convert JPEG/BMP/GIF to exactly that image format?
Sadly nope. I still am unsure how to make them. D: However, I know that it's 16 bits and uses 4 hex characters (such as 4EF8) for 1 pixel.By the way, is there any image<>hex converter that supports A1R5G5B5 format or something that can convert JPEG/BMP/GIF to exactly that image format?
Do you have any sample HEX strings? Just to see what endianness is needed. Once I got this I'll add an export option to my TI-Nspire sprite editor as Nspire Lua also uses A1R5G5B5 for its sprites.
Hello,
The code I'd posted previously (the little sprite command), shows how to load colors to a grob, and how to scale it.Code: [Select]EXPORT Sprite()
BEGIN
DIMGROB_P(G2,4,4,{ #7C0003E0001F0000:64, #0, #0, #7C0003E0001F0000:64 });
BLIT_P(G0,20,20,100,100,G2,RGB(0,0,0));
WAIT(3);
END;
Note that scaling is only a pixel by pixel things. It doesn't not interpolate. Also note that you can specify different source regions from the grob. This means you could have a larger grob containing a tileset, and blit in from a specific location.
You forgot to remove the WAIT(0.02) commands D:
That said, we already notice it's not even running at 50 FPS like the WAIT command tried to slow it down to, but there will be a speed gain if you remove it for sure.
You forgot to remove the WAIT(0.02) commands D:
That said, we already notice it's not even running at 50 FPS like the WAIT command tried to slow it down to, but there will be a speed gain if you remove it for sure.
Hmm that sucks >.<. I assume this means that our sprites (for example 16x16 tiles) will have to split into 16 chunks placed one after another vertically? (So if your game has 16 tiles that are 16x16, you would have a 4x1024 pixels GROB instead of 16x256). Then to draw the sprite, you would just use a For loop that scans through the 16 chunks vertically.Hello,
The code I'd posted previously (the little sprite command), shows how to load colors to a grob, and how to scale it.Code: [Select]EXPORT Sprite()
BEGIN
DIMGROB_P(G2,4,4,{ #7C0003E0001F0000:64, #0, #0, #7C0003E0001F0000:64 });
BLIT_P(G0,20,20,100,100,G2,RGB(0,0,0));
WAIT(3);
END;
Note that scaling is only a pixel by pixel things. It doesn't not interpolate. Also note that you can specify different source regions from the grob. This means you could have a larger grob containing a tileset, and blit in from a specific location.
I've tried some of my own 4x4 sprites and they work fine. However, I can't manage to go beyond 4x4 because I can't specify hex strings longer than 64 bits. Any way that bigger sprites can be done (using hex strings)?
That looks great! ;D By the way, how is the directional pad in the center? Does it feel solid, and is it responsive?
By the way, is there any image<>hex converter that supports A1R5G5B5 format or something that can convert JPEG/BMP/GIF to exactly that image format?
By the way, is there any image<>hex converter that supports A1R5G5B5 format or something that can convert JPEG/BMP/GIF to exactly that image format?
No, don't have anything for that. Sorry. (might tweak one and post it later though). It is a very basic encoding scheme though.
Basically, all that is happening is that you convert a #FF value into a linearly scaled #1F value. Here is a C macro that shows how this is done internally.
#define RGBToColor(R,G,B) (((R>>3)<<10)+((G>>3)<<5)+((B>>3))) // transforms 0-255 RGB into color
The 16 bit is just a flag that signifies transparency.
Note that the DIMGROB command just takes the information in order. So if you want to make a 6x3 grob, The first 4 16 bit groups come out of the first hex numb, the next hex num takes the first 2 and then the last 2 are the start of the second line and so on... { |#64bits, #(upper32)||(lower32), #64bits|,|#64bits,#(upper32bits)|(unused) }.
Each line in the 6 width takes the first 6 16 bit groups it finds. Each "line" of the grob is defined between the paired | |. Remember that all hex numbers, regardless of sign/unsigned/bits is internally 64 bits of data.
And here is a small converter for windows : img2prime.zip (http://www.mirari.fr/rPwG) (just drag and drop the image to convert on it) :)
(image)
It even handles transparency :P
But I'm not sure if the ":64" are always necessary.
{ #839B839B839B839B:64, #010001000100839B:64, #839B010001000100:64, #839B839B839B839B:64, #839B839B839B839B:64, #7DE17DE17DE10100:64, #01007DE17DE17DE1:64, #839B839B839B839B:64, #0100839B839B839B:64, #7DE17DE17DE17DE1:64, #7DE17DE17DE17DE1:64, #839B839B839B0100:64, #0100839B839B839B:64, #01007DE17DE17DE1:64, #7DE17DE17DE10100:64, #839B839B839B0100:64, #01000100839B839B:64, #010001007DE17DE1:64, #7DE17DE101000100:64, #839B839B01000100:64, #01000100839B839B:64, #7DE17DE101000100:64, #010001007DE17DE1:64, #839B839B01000100:64, #01007F6A0100839B:64, #7F6A7F6A7F6A7F6A:64, #7F6A7F6A7F6A7F6A:64, #839B01007F6A0100:64, #7F6A7F6A0100839B:64, #7F6A01007F6A7F6A:64, #7F6A7F6A01007F6A:64, #839B01007F6A7F6A:64, #01000100839B839B:64, #7F6A01007F6A7F6A:64, #7F6A7F6A01007F6A:64, #839B839B01000100:64, #0100839B839B839B:64, #7DE17F6A7F6A0100:64, #01007F6A7F6A7DE1:64, #839B839B839B0100:64, #01000100839B839B:64, #010001007DE17F6A:64, #7F6A7DE101000100:64, #839B839B01000100:64, #7F6A7F6A0100839B:64, #7DE17F6A7F6A0100:64, #01007F6A7F6A7DE1:64, #839B01007F6A7F6A:64, #7F6A7F6A0100839B:64, #7F6A7DE17DE10100:64, #01007DE17DE17F6A:64, #839B01007F6A7F6A:64, #01000100839B839B:64, #0100010001000100:64, #0100010001000100:64, #839B839B01000100:64, #0100839B839B839B:64, #010001007DE17DE1:64, #7DE17DE101000100:64, #839B839B839B0100:64, #839B839B839B839B:64, #839B010001000100:64, #010001000100839B:64, #839B839B839B839B:64 }Ok I've debugged my program, now it works perfectly :)
(image)
img2prime.zip (http://www.mirari.fr/mjJj)
bb010g > can you recompile it for linux ?
Also, you can now throw as many images as you want on it.
Btw does programs written in English mode work on French mode or vice-versa? I remember that on the TI-89 it wasn't the case.Yes, the functions names aren't translated since I think it's not tokenized so there are no problems of compatibility (luckily).
I'm planning to have a program to do sprites with RECTs by ThursdayIs that really more optimised than with GROBs ?
EXPORT Defender()
BEGIN
LOCAL xv:=10,yv:=20;
DIMGROB_P(G1,640, 48);
DIMGROB_P(G2,320,240);
Y:=32;
FOR X:=0 TO 640 DO
Y:=MIN(MAX(Y-1+IP(RANDOM(3)),0),47);
LINE_P(G1,X,48,X,48-Y);
FREEZE;
END;
RECT();
FOR X:=0 TO (640-64) DO
xv:=xv+2*(ISKEYDOWN(8)-ISKEYDOWN(7));
yv:=yv+2*(ISKEYDOWN(12)-ISKEYDOWN(2));
BLIT_P(G2,0,0,320,240,G1,X,0,X+64,48);
IF GETPIX_P(G2,xv+10,yv+5)==0 THEN BREAK; END;
RECT_P(G2,xv,yv,xv+10,yv+5,0,#20B2AAh);
BLIT_P(G0,G2);
END;
FOR N:=1 TO 100 DO INVERT_P; END;
END;EXPORT Scroll(s)
BEGIN
LOCAL x:=100,y:=100;
DIMGROB_P(G1,640,480);
FOR N:=1 TO 200 DO
RECT_P(G1,IP(RANDOM(640)),IP(RANDOM(480)),IP(RANDOM(640)),IP(RANDOM(480)),0,IP(RANDOM(255^3)));
END;
REPEAT
x:=MAX(MIN(x+ISKEYDOWN(8)-ISKEYDOWN(7),320),0);
y:=MAX(MIN(y+ISKEYDOWN(12)-ISKEYDOWN(2),240),0);
BLIT_P(G0,0,0,G1,x,y,320+x,240+y);
UNTIL ISKEYDOWN(4);
END;
Hi all,Wow that looks really cool and fun to play! One suggestion, though, would be to add colors and make the sky black like in the original game. It's a color screen, after all. ;)
2 examples of programs and videos with the hardware :
http://www.dailymotion.com/video/x132v9e_defender_tech (http://www.dailymotion.com/video/x132v9e_defender_tech)Code: [Select]EXPORT Defender()
BEGIN
LOCAL xv:=10,yv:=20;
DIMGROB_P(G1,640, 48);
DIMGROB_P(G2,320,240);
Y:=32;
FOR X:=0 TO 640 DO
Y:=MIN(MAX(Y-1+IP(RANDOM(3)),0),47);
LINE_P(G1,X,48,X,48-Y);
FREEZE;
END;
RECT();
FOR X:=0 TO (640-64) DO
xv:=xv+2*(ISKEYDOWN(8)-ISKEYDOWN(7));
yv:=yv+2*(ISKEYDOWN(12)-ISKEYDOWN(2));
BLIT_P(G2,0,0,320,240,G1,X,0,X+64,48);
IF GETPIX_P(G2,xv+10,yv+5)==0 THEN BREAK; END;
RECT_P(G2,xv,yv,xv+10,yv+5,0,#20B2AAh);
BLIT_P(G0,G2);
END;
FOR N:=1 TO 100 DO INVERT_P; END;
END;
I tried the same program with a 40*20 pixels for the spaceship and it run at the same speed
Scroll(1) ->1 pixel scroll :D
http://www.dailymotion.com/video/x130nft_scroll-prime_tech (http://www.dailymotion.com/video/x130nft_scroll-prime_tech)Code: [Select]EXPORT Scroll(s)
BEGIN
LOCAL x:=100,y:=100;
DIMGROB_P(G1,640,480);
FOR N:=1 TO 200 DO
RECT_P(G1,IP(RANDOM(640)),IP(RANDOM(480)),IP(RANDOM(640)),IP(RANDOM(480)),0,IP(RANDOM(255^3)));
END;
REPEAT
x:=MAX(MIN(x+ISKEYDOWN(8)-ISKEYDOWN(7),320),0);
y:=MAX(MIN(y+ISKEYDOWN(12)-ISKEYDOWN(2),240),0);
BLIT_P(G0,0,0,G1,x,y,320+x,240+y);
UNTIL ISKEYDOWN(4);
END;
Try to keep NES, SNES and such emulators for later if you code one, though, because as soon as we got emulators on the Nspire, this pretty much killed game development on the platform :(Emulators do have their share of responsibility in the fact that native Nspire ports / brand-new games are relatively scarce, but I think that the very facts the platform is a closed one, and TI repeatedly actively fights developers, have an even greater responsibility :)
I'll get this if it is <$150 and has C/Asm support.It's supposed to be around this price tag, but it has been made clear that it has no native code support either.
Hey Gilles59, that's some great looking stuff. :D Thanks for sharing, and welcome to Omnimaga.
I've no time for now but I did some little tests with the small skeletton of the 'defender' program (change color, use sprites, kind of 'radar' in the upper of the screen...). I think the integrated langage of the prime is fast enough for fluid programs like tretis, 'snake', space invader ... even with scrolling...
EXPORT Rota
BEGIN
LOCAL sa,ca;
DIMGROB(G1,40,40);
RECT_P(99,79,140,120,0,RGB(255,255,255));
FOR A:=0 TO 10*PI STEP PI/12 DO
RECT_P(G1);
sa:=SIN(-A); ca:=COS(-A);
FOR X:=-20 TO 20 DO
FOR Y:=-20 TO 20 DO
PIXON_P(G1,X+20,Y+20,GETPIX_P(G0,X*ca-Y*sa+20,X*sa+Y*ca+20));
END;
END;
BLIT_P(G0,100,80,140,120,G1,0,0,40,40);
END;
WAIT();
END;
Wow 5 FPS is actually pretty darn good considering that is BASIC. Even the CSE has an hard time pulling this with pure ASM when in 320x240 mode.
SO basically no scrolling unless you want your game to scroll tile by tile, but pretty fast sprite movement and no long map loading :D
Now to figure out how to avoid having to keep a bunch of tiles displayed to the right side of the screen >.<
actually that post you quoted was kinda old and outdated, since I figured out since then why DIMGROB and BlIT weren't working with G1 to G9. Thanks anyway though!Wow 5 FPS is actually pretty darn good considering that is BASIC. Even the CSE has an hard time pulling this with pure ASM when in 320x240 mode.
SO basically no scrolling unless you want your game to scroll tile by tile, but pretty fast sprite movement and no long map loading :D
Now to figure out how to avoid having to keep a bunch of tiles displayed to the right side of the screen >.<
Hi, Just try :
EXPORT Sprite()
BEGIN
DIMGROB(G1,16,239);
FOR Z FROM 0 TO 239 DO
RECT_P(G1,0,Z,16,Z+1,RGB(IP(RANDOM(256)),Z,240-Z));
END;
WHILE 1 DO
FOR X FROM 0 TO 19 DO
FOR Y FROM 0 TO 14 DO
V:=16*IP(RANDOM(14));
BLIT_P(G0,16*X,16*Y,G1,0,V,16,V+16);
END;
END;
END;
END;
It's cuirous that INT works for Integer Part. The correct keyword accordind the help is IP (INT is for calculate Integral)