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.
Messages - Runer112
1
« on: April 04, 2019, 11:03:16 pm »
... except you have to work with an edit buffer for that, because home screen input works by having that program open in an edit buffer.
2
« on: February 13, 2019, 11:43:17 pm »
3
« on: November 07, 2018, 01:55:38 pm »
In that case, there's really no good option other than to ditch BASIC. It sounds like you might want to try ICE instead of BASIC.
4
« on: October 29, 2018, 12:40:31 pm »
Does Pt-On() only take pointers? I seem to remember that Pt-On(0,0,[FFFFFFFFFFFFFFFF]) also works.
[FFFFFFFFFFFFFFFF] is a pointer. It statically allocates data as well, but the "return" value is a pointer. You should be able to use it in any expression, although I think you may need to enclose it in parentheses in some cases to avoid confusing the compiler.
5
« on: October 29, 2018, 11:52:00 am »
This doesn't seem be documented anywhere, but reading from files requires special logic. The only commands that have variants implementing this special logic are {PTR}, {PTR}r, and Copy(PTR1,PTR2,SIZE).
In your case, you'd need to copy the sprite out of the file and into a buffer in RAM, and then display the sprite from that buffer. Note that this will add some major overhead if the file is in fact archived; it'll make displaying an 8*8 sprite take about twice as much time.
6
« on: June 16, 2017, 04:26:13 pm »
The axiom Fullrene should allow you to bypass the 8KB program code limit. There are mixed reports of its efficacy, though. Also, the program needs to be launched from a shell, as the OS simply refuses to launch programs this large.
Alternatively, compile your code as an application to get a bit under 16KB of room, although this may not be desirable for other reasons.
Interrupts being enabled or not should have no bearing on this.
Fullrene uses interrupts to disable the limit. If you read the source, you will see that it uses the I register for interrupts. I know that zStart has a hack to disable the limit, but I don't know if it simply removes the limit firm the OS itself. I don't know about crabcake. I couldn't find a download for it anywhere. Compiling as an app is not an option for me currently for various reasons.
It uses the i register as part of the logic to disable the code limit, but it doesn't use interrupts or the i register after that. The limit is not removed permanently; it is only removed for the remainder of the program's execution. Important edit: does → doen't
7
« on: June 13, 2017, 06:06:28 pm »
The axiom Fullrene should allow you to bypass the 8KB program code limit. There are mixed reports of its efficacy, though. Also, the program needs to be launched from a shell, as the OS simply refuses to launch programs this large. Alternatively, compile your code as an application to get a bit under 16KB of room, although this may not be desirable for other reasons. Interrupts being enabled or not should have no bearing on this.
8
« on: January 27, 2017, 11:57:50 pm »
No clue. Never heard of something like that before.
9
« on: January 27, 2017, 08:58:24 pm »
There is no computer version of the compiler. The closest thing is just running Axe in an emulator and compiling programs in the emulator.
10
« on: January 24, 2017, 09:07:10 pm »
"Matrices" in Axe generally just mean blocks of data that you treat like a matrix. There is no built-in support for matrices, but given a W*H*Z block of memory pointed to by M, it can be treated like a matrix of width W, height H, and entry size Z. An element (X,Y) can be addressed with Y*W+X*Z+M (note that order of operations in Axe is left-to-right so Y*W+X, not just X, is multiplied by Z).
11
« on: January 22, 2017, 02:52:07 pm »
So, first. Is it possible to store data to a single nib, or nibble of data? If it is possible, how would I do so? This would be very helpful in gamemaking, with things like coins.
The answer can be found in the command list. Just like you can read from a byte address with {PTR} and store to a byte address with →{PTR}, you can read from a nibble address with nib{PTR} (really the iPart( token) and store to a nibble address with →nib{PTR}. As explained in the command list entry, nibble pointers should be multiplied by two, as there are two nibbles in a byte. And, next. Is there a specific sprite editing tool for making files compatible with the TI-84+? If so, where can I download it? I feel like making nice title screens for games, but I don't know where to look.
For making sprites on-calc, the best tool is certainly tileIt!, a sprite and tilemap editor made especially for Axe. For making sprites off-calc, you have a couple of options. I think one of the best options for Axe is Pixelscape, an online tool also made especially for Axe and with compatibility with tileIt!.
12
« on: January 04, 2017, 05:42:12 pm »
Very small, pixel art images generally don't look good when geometrically transformed, which includes rotation (by a non-right angle). I would recommend using a tool like RotSprite to generate rotated sprites at even intervals up to 90 degrees and touch them up by hand, and then these can be rotated by right angles in the program using the rotC() and rotCC commands to fill out the three missing quadrants of rotation from the one you have.
13
« on: January 04, 2017, 12:42:41 pm »
While I'm talking to Runner112, I might as well ask, whatever happened to that program you were making that upscaled a sprite, rotated it, then downscaled it again? Did you finish it? Because it'd be really helpful for this one game I want to make. I couldn't find it when I was reading the forum you talked about it on.
I vaguely remember trying something like that, but I don't believe it panned out. If you're looking to create rotated versions of sprites, I would recommend doing so ahead of time on a computer with a tool like RotSprite. EDIT: For those wondering, I believe I found the thread in question where my failed attempt lives: [AC] rotating sprites.
14
« on: January 04, 2017, 12:36:39 pm »
Axe does support signed numbers, in two's complement form. When a value "loops back to the highest number" as you say, it is treated as negative for the purpose of signed operations. However, Axe doesn't have types attached to values, and many basic operations use unsigned logic because it's simpler/faster. But in most (all?) of these cases, a signed version of the operator exists, usually denoted by repeating the operator. For instance: // for signed division, >> for signed greater than, etc. All of the signed operators can be found in the "Advanced Math" section of the command list. Also, keep in mind the rather strange range and domain of Axe's sine and cosine functions: a period is 256 units rather than 2𝜋, and the output range is [-127, 127] rather than [-1, 1]. It's also not totally accurate. All of these quirks are because it was designed with the main goal of being quick and dirty.
15
« on: January 03, 2017, 05:34:54 pm »
The appearance of different contrast (shade) values varies from calculator to calculator. There's no fixed good number. Many programs/games just rely on the user to set a good contrast value beforehand in the OS.
Some may also implement a tuner in their program that allows the user to adjust the contrast for their program, distinct from the OS. GrayLib provides such functionality with the GTune() function. If you're going to use this part of GrayLib, though, you should probably consider just using the whole thing.
|
Show Posts
