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 - calc84maniac
Pages: 1 ... 145 146 [147] 148 149 ... 197
2191
« on: April 11, 2010, 12:49:18 am »
2) What do you mean by "Switch statement" in the features wishlist? I think I heard it mentionned before but I totally forgot 
It is meant to replace a bunch of If/Else statements with A=0, A=1, A=2, A=3, etc, replaced with a faster and smaller solution (or something like that)
2192
« on: April 09, 2010, 09:05:47 pm »
Some Ion progs work as no stub also I think.
Not all of them and some will crash. Galaxian works pretty well no-stub, but Ztetris will cause a RAM clear on exit. I think Galaxian also caused certain errors on later OSes.
I guess maybe a no-stub and Mirage version could be a good idea in the future.
Btw nice so far, you might want to fix a few collision detection bugs, though, such as character sometimes getting stuck into the floor when falling from very high or his head in the ceiling when jumping very high. But again I doubt you'll just this high in final version so I guess this migth not be a problem as much 
I believe I made Grayscale Minesweeper and Grayscale Tunnel with support for both Ion and no-stub
2193
« on: April 09, 2010, 07:38:01 pm »
the 83+ has 2 hardware timers
the 83+SE had 2 hardware timers and 3 crystal timers
the 84+ has 2 hardware timers, 3 crystal timers, and a clock.
I'm almost certain that the 83+SE does not have crystal timers, where did you get that information? And what do you mean by hardware timers?
You can make your own timers with interrupts once I get that working.
83+SE certainly does have crystal timers. The only hardware difference between TI-83+SE and TI-84+SE is the real-time clock and the USB.
2194
« on: April 08, 2010, 11:35:04 pm »
I'm a bit confused about map resolution constraints. 6x4 would only be a single screen. We're talking about entire dungeon and town maps, here. I know I've seen much larger maps, unless I'm mistaken.
32x32 sounds fairly reasonable. I'm just not sure if that would be adequate for a world map, on the other hand.
New question: What if the tileset were 24x24px? Would this affect any resolution constraints?
I think "resolution" was a confusing word to use, because it generally refers to screen size. And xLib only supports tilesets of 8x8 and 16x16 (and 24x24 would be far too large in the screen to have any good view anyway)
2195
« on: April 08, 2010, 11:11:07 pm »
Also, keep in mind that smooth-scrolling is not supported -- tilemaps are only drawn aligned to the nearest multiple of 8 or 16 pixels, depending on the tile size.
2196
« on: April 08, 2010, 10:29:01 pm »
If by Tilesets you mean a single picture, then its inly 256, but because of the fact that xlib is awesome, the 257th tile is the first tile from the next picture # eg. pic 10 to pic 11, so thats how the constraint is just memory. Just wanted to make sure that was explained. =P
Well, 256 tiles don't fit into one Pic file. But it still wraps after 96 (or I suppose 24 for 16x16 tiles)
2197
« on: April 08, 2010, 10:08:12 pm »
in java, its for(variable;condition;what to do to make the variable approach the condition)
usually something along the lines of for(int i=0;i>5;i++)
a > condition will behave like BASIC and Axe, but if you did i=5 and started with i=6 or something, it would behave strangely, either giving a compile time error, or incrementing until i overflows and becomes 5.
I think you mean a < condition, because it acts like a "while" and not "repeat"
2198
« on: April 08, 2010, 02:23:31 pm »
No, after looking at the documentation, it appears to be done a different way (I have not tested this myself).
First of all, I can tell you that "LX" will not work. You can only use L1-L6, and all those are is places in the RAM. You don't actually modify user lists.
Now, assuming that you have all of your data in L1, this is how you would save it to the AppVar POKE:
Select(POKE) // Select the AppVar POKE
Unarchive POKE // Unarchive it if it already exists
GetCalc(27)->A // Create/Overwrite an AppVar 27 bytes in size
conj(L1,A,27) // Copy L1 to the AppVar
And to read from it:
Select(POKE) // Select it
Unarchive POKE // Unarchive it if it exists
GetCalc()->A // Get a pointer to it
!If A
// It doesn't exist
Else
conj(A,L1,27) // Load the data to L1
End That's not how you use the file commands. You will need to do this: "POKE->Str1
Select(Str1) // Select the AppVar POKE
If GetCalc(27)->A // Create/Overwrite an AppVar 27 bytes in size
conj(L1,A,27) // Copy L1 to the AppVar
Else
// Not enough memory
End
2199
« on: April 07, 2010, 11:06:42 pm »
I was reading about linking, and would it be faster to have one line be a clock, and then the other line be the bit to be sent? When the receiving calc detects a change in the clock line, it inputs the bit line into memory. Seems like it would be faster? I'm just theorizing tho
The problem here is that bits may be skipped. Not good 
2200
« on: April 07, 2010, 10:03:54 pm »
Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.
Although, I'm not a guru on linking. I know that the ports on each calc mimic each other, so it might be a good idea to assign a random bit, high or low, to each calculator, in which case you can only send one bit at a time.
Well, there are two link lines, but only one bit can be sent at once. The sending calculator pulls either line A or line B low, depending on the value of the bit being sent. The receiving calculator acknowledges by pulling the other line low. Then the sending calc lets its line up, and the receiving calc lets its line up.
2201
« on: April 07, 2010, 06:32:56 pm »
Or use calc84's utility.
Even that is annoying though 
2202
« on: April 07, 2010, 12:19:00 pm »
Ok. Fair enough. And what about text commands. If I wanted to display simple text on the homescreen, how would i do it.
I'm pretty sure this info is in the Axe documentation
2203
« on: April 07, 2010, 11:57:40 am »
96?!? 64?!? Blashphemy!
I'm pretty sure it's 95x63, that's what I use.
That's how much is accessible in pure Basic, but with Axe and ASM there are no such limits. Edit: Wow I was double ninja'd
2204
« on: April 07, 2010, 07:19:59 am »
Regarding features, there's something I wonder... would support for 4 bits integers be something very hard to implement? In the cases where people use one byte for two tiles in a tilemap data, for example, maybe it would make it easier for people to work with the data, as they wouldn't need to remember how to write routines to split it.
If you have a byte A with two 4-bit numbers packed in it, you can extract them with A/16 and A^16 Edit: If you want greater speed, use A*16/256 instead of A/16 so it doesn't have to do any real division
2205
« on: April 06, 2010, 11:27:08 pm »
Well, I think there may be some confusion here. The screen is 95x63 pixels in size. That is a total of 5985 pixels. The graph buffer is not 5989 bytes long. It is 748 bytes long. This works because it is monochrome (black and white). A pixel is only ever on, or off. Because of that, you can use binary. There are 8 bits to a single byte, so if you wanted a dotted line, you could write 01010101b to the graph buffer.
Why this matters is that you can't just write a 1 to the graph buffer and expect a single pixel to change. From what I know of Axe, it would be very hard indeed to manually change each pixel.
It is 96x64 actually, and 768 bytes
Pages: 1 ... 145 146 [147] 148 149 ... 197
|
Show Posts