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
Pages: 1 ... 138 139 [140] 141 142 ... 153
2086
« on: July 31, 2010, 12:20:44 pm »
Admittedly, it would be sick. But unfortunately its uses would be limited due to its inability to be used in realtime games. That's why I voted for Mode 7, it's probably the most reasonable option in terms of realtime usage.
2087
« on: July 31, 2010, 12:14:36 pm »
I'm for polygons and mesh. This, folks, is the same kind of 3D you get on a computer! I would vote there, too, if I were you.
The question is, could you get a polygon engine to run quickly?
2088
« on: July 31, 2010, 11:25:49 am »
This site is aimed at the GBA, but it still wonderfully explains/demonstrates Mode 7 and provides, albeit customized for C programming and the GBA, the math behind it: http://www.coranac.com/tonc/text/mode7.htmhttp://www.coranac.com/tonc/text/mode7ex.htmFor Mode 7, you'd probably need something like the following: - New two-byte variables to which to store the pointer to a tilemap, the size of the tilemap, and a pointer to the tileset (the special u, v, and w characters?)
- New one/two-byte variables for camera x and y position (X1T/Y1T?)
- New one/two-byte variables for camera x and y direction (X2T/Y2T?)
- A new one-byte variable for camera zoom (X3T?)
- A new one-byte variable for camera height (Y3T?)
- And the routine of course
Or you could just have the routine require all these inputted as arguments, but that would require the programmer to either give up a lot of the existing variables for this or designate annoying extra variables like {711+L 1} r, {709+L 1} r, etc.
2089
« on: July 31, 2010, 10:44:39 am »
Any/all of these would be amazing, but I think the one that would work the fastest and therefore have more uses is Mode 7.
2090
« on: July 31, 2010, 10:34:46 am »
Good news! I've found the source of that error where the high nibble sometimes gets changed to a 0. My byte reading routine was supposed to preserve certain registers and I forgot that I changed that routine by adding another subroutine to it that shows the current progress percentage and that subroutine did not preserve those registers when it updated the percentage to the screen (which happens very rarely).
So this is the source of my hexadecimal parsing error? One thing I did notice is that the percentage counter updates while parsing hexadecimal data in 0.4.0 and above, and that's when the problem appeared. I was even thinking to myself, asking if that could be the cause of the problem, but I figured it probably wasn't and didn't think to mention it lol. EDIT: Oh, and on the topic of the percent counter, there's another bug, although it has no adverse affects and will hardly ever show up: if the program you're compiling is absolutely massive (like both of the 2 ~48K uncompressed map data source files I have), the percent counter loops back around to 0 percent in the middle of compiling, I believe once ~32768 bytes have been processed.
2091
« on: July 30, 2010, 03:18:50 am »
The reason I was doing stuff with /213 is because I'm working on an animation driven by a timer variable being increased in an interrupt. To get the timing right, one of the parts of the animation involves sine and cosine that need to have periods of 213, so I use C^213*256/213 as a period modifier.
2092
« on: July 30, 2010, 12:26:32 am »
Haha wow, the OS division routine doesn't work properly? How have I been the only one to discover this?
2093
« on: July 29, 2010, 11:40:22 pm »
GN does not explicitly return 1 or 0, it returns the half byte tile 0-F (0-15 in decimal). Although personally, I don't like that routine since there is no X and Y its usage is confusing.
If you want a solid gameboy gray, you have to turn interrupts off for the entire code and you also need to make sure to adjust the pause time in between each DispGraph to the perfect amount. It will take some tuning since every display is different unfortunately. For me, I have a TI-84 Plus K-0108H and my perfect gray setting is this:
:FnOff
:Repeat getkey(15)
:
:Pause 7 ;Long pause
:For(A,0,15):End ;Fine tuning
:
:DispGraphr
:End
By perfect, I mean like a gameboy, not even one of those slowly scanning lines that moves diagonally from one side to the other, I mean literal gray. The pause times will of course have to be different depending on how much other code you have in your loop.
Why do interrupts have to be off for good-looking grays?
2094
« on: July 29, 2010, 11:25:15 pm »
I'm having some problems with division... I was trying to debug the problem in my program with this:
Text(0,52,C^213*256▸Dec)
Text(0,58,C^213*256/213▸Dec)
The only difference between these two lines is that one has a /213 at the end. When I run the program, the output is (almost always) incorrect.
I attached a sample program I quickly whipped up to further demonstrate the problem. Almost every division is incorrect, although a few are correct. The divisions always seem to result, in order of commonness: 0s, powers of 2, 18 times powers of 2, 66 times powers of 2, 68 times powers of 2, and if and only if C^213 equals 114, the correct answer of 137.
2095
« on: July 29, 2010, 04:55:43 pm »
Just wondering... why store pictures in strings and not pictutres?
2096
« on: July 29, 2010, 06:04:35 am »
I did not read through most of the discussion, but Runer, are you actually planning to ditch the entire hard work you put on the 4 level grayscale tiles and converting to 3 level maps? Or am I misunderstanding? Although 3 level may look nice too, it would suck to have to restart from scratch 
Otherwise, do you just mean the sprites that requires masking?
The background tiles in the game are all 4-level grayscale, as they are the bottom layer and thus don't need transparency. However, all the foregronud sprites, such as items, people, creatures, etc. are 3-level grayscale in the game. The question is, should I/others who may help me with sprites use only 3-level grayscale for easier masking? Or 4-level transparency for (an undetermined amount of) better visual quality? Tomorrow I might try testing the game with about 16 random sprites on the screen, which would cover most situations. If it still runs decently fast with 4-level grayscale foreground sprites, then that will probably be the way to go. Otherwise, 3-level grayscale sprites.
2097
« on: July 29, 2010, 01:14:33 am »
I always have the auto opts file open when I'm coding, to try to keep my programs as small as possible. However, this just shows the size of things that are automatically optimized. Could you add a file that doesn't show optimization sizes, but just command/operation sizes in general?
2098
« on: July 28, 2010, 09:10:27 pm »
How did I not find this before, that was incredibly easy
2099
« on: July 28, 2010, 08:56:12 pm »
I've tried multiple different pieces of software multiple times, and I can never seem to find a way to dump my 84+ SE's ROM. It's never been a problem for me in the past. I actually was looking for TI-BASIC editors a while ago and one happened to come across one that was secretly bundled with VTI and a TI-83+ ROM (they better hope TI doesn't find out about this). But anyways, I haven't had any problems with this ancient 83+, non-SE, OS 1.12 ROM. Until now.
I'm using a new computer, and wabbitemu just doesn't seem to work properly. It's probably my computer, so I'm installing VMWare Player with an old XP disc as I'm typing this, in hopes that wabbitemu will work fine on that. However, it may just be my computer not liking the ROM, and having a ROM with a really old OS and not much archive space wasn't too fun to work with anyways.
tl;dr best/easiest way to dump a TI-84+ SE ROM?
2100
« on: July 28, 2010, 07:59:12 pm »
Do you plan on keeping Link in 3 grayscale using the dark gray as a transparency or do you have something else in mind?
Oh, didn't notice this post. Obviously things would be easier on the programming side and quicker on the performance side, although it would be harder to convert all the foreground sprites to 8x8 with only 1 shade of gray. Can you try a few sprites in both 3 and 4? I figure if I'm going to decide whether or not 3 colors is enough, I should let someone good try a few and see how the come out.
Pages: 1 ... 138 139 [140] 141 142 ... 153
|
Show Posts