I get exactly this on both my 83+BE (with interrupt 4) and my 84+SE (with interrupt 0), with just the little "scrolling glitch line", as you say However, the grey is not that perfect on my sister's calc, whatever the interrupt I choose
edit: here is what I get with Wabbitemu set at 68 Hz and 5 shades with this program .AA FnOff ClrDrawrr Fill(L3+252,252,255) Fill(L6+252+252,252,255) fnInt(DG,0) Pause 200 While 1 EndIf getKey(0) LnReg Return
(omg, the latest version was downloaded 258 times )
Also, I thought about something. Would it be possible to increase the viewing range in some way by drawing near cubes using 3d (what you are currently doing) and drawing the remaining cubes (the ones that are far) with ugly rectangles or so ? This way, you don't use 3d for every cube (so speed is saved) and we still somehow see a bit further ?
(please tell me where I made typos, I am sure I made some )
With my recent work on TinyCraft, people have been asking me how I make my grayscale so beautiful. So here is a tutorial! (what do you mean by "you stole thepenguin's sentence" ? )
So one day, I read thepenguin's tutorial to see if I could get something to work in Axe on a 83+BE without Full speed and I understood that I had to refresh the screen 50-60 times per second.
Now, How would you do this in Axe ? With a loop that runs exactly at 50 Hz ? Not really, for two reasons: - maybe your calc will have beautiful grey at 50 Hz but others may hae it beautiful at 52 Hz - maybe the loop will run at 50 Hz on your calc but will run at 48 Hz on others
So you need interrupts. If you don't know how interrupts work, check out Hot Dog's tutorial. Problem: the slowest interrupts still runs at a higher frequency than 100 Hz, there is no interrupt at 50 Hz. But who told you that the screen was actually refreshed every time the interrupt runs ?
The speeds for the interrupts are as follow (according to Hot Dog):
So: -with speed 0, we would need to refresh the screen only 1 time every ten runs, because 50<560/10<60 -with speed 6, we would need to refresh the screen only 1 time every 2 runs, because 50<118/2<60 -etc
Let's make a try with speed 0 for example. Then, it will be easy to get it to work with arbitrary speeds So for educationnal reasons, we are going to make a stupid and unoptimized program that will include beautiful grey. Note that I don't code so bad in real life Let's draw for example two rectangles, one black, the other one grey. .AA ClrDrawrr Rect(0,0,8,8,L3) Rect(0,8,8,8,L6)
Now we need to set up the interrupt. We use speed 0 so we need to refresh the screen 1 time every 10 runs. We need a counter that will tell the calculator if it should refresh or not. So the routine used as an interrupt should look like this. Lbl DG T+1?T If T=10 0?T DispGraphr End Return
Another solution would be this one Lbl DG T+1?T !If T^10 DispGraphr End Return
And now, the only thing we need is to set this interrupt on to refresh the screen automatically .AA FnOff ClrDrawrr Rect(0,0,8,8,L3) Rect(0,8,8,8,L6) 0?T fnInt(DG,0) Repeat getKey(0) End LnReg Return
Lbl DG T+1?T !If T^10 DispGraphr End Return
If you want a little more optimised version of this, here it is .AA FnOff ClrDrawrr Rect(0,,8,,L3) Rect(0?T,8,,,L6) fnInt(DG,0) While 1 EndIf getKey(0) LnReg Return
Lbl DG !If T++^10 DispGraphr End Return
If you want a faster-than-light or a smaller-than-0-bytes version of this, ask Runer112.
Now, the only thing that is missing in that tutorial is "how to make a calibration screen ?", but I am sure you can do this without my help. You just need to make a menu that will select between 4 values and each value gives an interupt speed and a timer-max.
Notes: I made an example with 3 levels of grey but it works with 4 levels too See TinyCraft for example.
Disadvantages of this method: -First of all, the screen is automatically refreshed. This means two bad things: this will make you forget your good habit to make "DispGraph"s inside your loops, and sometimes, you only want to refresh after it cleared all and redraw all, but now you can't choose anymore where the refreshing will happen -For some reason, using the Text() command on a regular 83+ (not SE) kills the interrupt (but everything else in the program runs fine). To avoid problems, you can use Jacobly's TEXT Axiom or simply avoid the Text() command when the interrupt is running (disable it before using Text() then put it back for example, or prerender all the text in your menus instead of putting the Text() commands in the loop).
I am a newbie regarding TI-Nspire Lua programming (got my CX CAS this week, immediately updated to OS v3.2).
Then you might not know that the OS 3.2 blocks Ndless, so you can't run any native program anymore (like the GBA emulator, Doom, nTNOC (to get more free space), mViewer (to see images on your calculator), etc). I am not telling you to downgrade in anyway, if you don't care about Ndless, that is your choice, but I still wanted to warn you in case you didn't know about that choice
Both take 68 bytes of source code but the first one takes 274 bytes of compiled code while the second one takes 386 bytes. And they both do the same thing (draw two black squares). Why so ? Because the first one only uses the Pt-Off routine, while the second one uses the Pt-Off routine and the Rect routine, adding bytes to the executable
I have problems running it. I run it with zStart, with MirageOS absorbed but then it says that the ZAB5E1F1 file is missing even though I have it in my archive
I am checking it out know but, I have a quick question for you. Are you only using the files that were in the archive I posted or are you using files that are from before hand?
Well, I think I use the files from the archive. I unzipped the zip and followed the instructions.
Yeah, I saw on TI-Planet people who asked for a gif player on Nspire, so that would be cool if they could convert their gifs into videos then convert them for NspireMoviePlayer
Ok, I made another try and it still didn't work Here is the total output of the command prompt, in the spoiler.
F:\TI 83 Plus\NSPIRE CX CAS\NDLESS\nspire movie player v0.1.1\xacto\ffmpeg\ bin>moviecompile "F:\TI 83 Plus\NSPIRE CX CAS\NDLESS\nspire movie player v0 .1.1\xacto\ffmpeg\bin" MovieNameHere.nmp.tns 15
F:\TI 83 Plus\NSPIRE CX CAS\NDLESS\nspire movie player v0.1.1\xacto\ffmpeg\ bin>
edit: karmTI doesn't even want to receive the produced tns, transferring doesn't work. Maybe a header problem or something ??
Also, I thought about something that may be a faster way to draw the cubes but I am not sure if that will work so I first need to know some things: -can you draw arbitrary sizes of sprites with Ndless C ? -can those sprites support transparency ?
I don't think that ndless does that, but it's quite easy to code. Why ?
Well I thought about a 3d drawing method that could speed up the game, but I am not really sure. Basically, it is based on the isometric 3d idea.
In isometric 3d, all the cubes are the same, so you only need to draw one in 3d, then use the image of this cube as a masked sprite to draw all the other ones.
In non isometric 3d, one cube is not enough since not all the cubes are seen from the same angle, but one cube per line is enough. If you have n aligned cubes you draw one of them using your current 3d engine, then use the image of this cube as a masked sprite to draw the other ones, using some sprite scaling.
So basically, if you have n lines of m cubes each, you don't need to draw n*m cubes in 3d but only n cubes and n*m sprites.
Do you get what I mean (or is my English really bad ) ?
You can't create a 2 page app with axe, due to RAM restrictions.
Yes, but I said "or isn't there a method with uncompiling the app then recompiling again" Also, it could first compile the first page then start over with fresh ram to compile the second one, so still no ram restriction