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 - Quigibo
Pages: 1 ... 64 65 [66] 67 68 ... 135
976
« on: August 01, 2010, 05:38:45 pm »
That should probably go in the features wishlist, but to answer your question, its definitely possible, but I don't think I will because I'm already having enough issues with app compiling, it would be even more chaotic with yet another way to risk damaging archive space only this time, it would be more likely to corrupt actual programs and other variables rather than application pages.
977
« on: August 01, 2010, 02:44:32 pm »
Programs can be larger than 16kb since they can take up all available ram, they just can't be executed. Runer is using those programs as read only memory so he doesn't have that problem. But I didn't know myself that programs could be larger that the available RAM! I guess they would have to be archive only, made on the computer, and then transferred.
978
« on: July 31, 2010, 02:47:10 pm »
Polygons wouldn't be that slow as long as there was a small count. I'd imagine that you could get a decent real time game with 50 onscreen edges with more off-screen.
By the way, I was working on a mode 7 engine myself in the actual Axe Language. At first it was really slow, less than 1fps, but i kept doing more and more optimizations and now I can get the entire lower half of the screen in mode 7 grayscale at about 8-10 fps which definitely has game potential. However, I don't have rotation, just translation, incline, and FOV.
If I implement any of the 3D modes, the routines are going to be gigantic (probably combined 500-1000 bytes) since I won't care about size, just speed.
979
« on: July 31, 2010, 03:22:23 am »
I decided to stop the poll since I will probably have time for all 3 of those features next version. Instead, I've decided to ask a more interesting one for a feature I don't plan on adding anytime soon if at all, but I'm very interested in what everyone will think of this. If you're not sure what each option is referring to, all examples are the Super Nintendo versions of the game, you can see some videos of the games on YouTube to clarify.
980
« on: July 30, 2010, 09:23:25 pm »
The getkey's have to be in Normal speed otherwise they sometimes don't register the correct keys. Your DS routine is taking up 99% of the CPU anyway so the other stuff is a negligible speed difference. Don't forget, Full speed is not available for the regular TI-83+ which would still run at Normal speed after that command. So your program won't be the same quality with that calculator.
981
« on: July 30, 2010, 09:14:12 pm »
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).
982
« on: July 30, 2010, 07:57:19 pm »
You can put your sub(DS) in full speed mode. Just add a :Full to the start of that subroutine and a :Normal at the end of it. By the way, I just noticed you don't have a return at the end of it so its falling through to the next subroutine and returning after that.
983
« on: July 30, 2010, 06:31:09 pm »
You don't need that pause 7 there anymore. That was only there originally because I didn't have enough pause in the example I gave. Your drawing routine plus everything else in the loop already has a huge pause, probably longer than a pause 7 so you don't need that extra pausing since its just slowing it down.
984
« on: July 30, 2010, 01:33:09 am »
Ah, so its really 16-bit / 7-bit then. In that case, the name is really deceiving, maybe I should mention this in the WikiTi for that bcall. I might just change the auto-opt to use this optimization only if the constant is smaller than 128 and just use my normal 16 bit division routine otherwise.
Hmm... but that routine is faster for 8-bit numbers. I wonder if it wouldn't be too much overhead to have single routine for both 8-bit and 16-bit divisions that checks if the input is 16-bit or 8-bit at the start and then branches to the correct routine. I feel this might be a large enough speed increase to justify the extra size since i think a majority of divisions are with numbers smaller than 256 which will all be sped up almost double, both when using constants and variables. It would be about 20 extra bytes to the subroutine and only 1 extra byte when calling the routine with a constants smaller than 128 (unless otherwise optimized). This would also increase the speed of signed division. Can I get some opinions on this?
985
« on: July 29, 2010, 11:53:14 pm »
That's bizarre... the routine isn't mine though it's TI's! I'm using BCALL(_DivHLByA) and the disassembly is showing the executable is setting up the inputs correctly so it must be something wrong with their routine. I'm going to investigate.
Most interesting! With the following input:
ld hl,25600
ld a,213
I disassembled the exact routine the OS uses. Running the input through this exact routine:
push bc
ld c,a
sub a
ld b,16
loop:
add hl,hl
rla
cp c
jr c,skip
sub c
inc l
skip:
djnz loop
pop bc
Does indeed return the result "0" in HL instead of "120" like it should. Am I misusing something here? This is a 16-bit / 8-bit division right? Why is it failing?
986
« on: July 29, 2010, 11:14:14 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.
987
« on: July 29, 2010, 09:02:33 pm »
Yeah they're just by 90 degrees. I've finished all the routines, I just need to implement the commands now. The output sprite needs to be at least sqrt(2) times larger else there will be clipping during the rotation.
988
« on: July 29, 2010, 08:53:06 pm »
In fact you should ONLY use free ram to hold your variables and arrays (unless you run out or need larger dimensions) since using static pointers are just a form of self-modifying code and therefore adds extra size to the program. Your program wouldn't be compatible as an app either if it uses SMC.
EDIT: Also LordConiupiter, you need the r modifier there since you're holding a 2 byte number.
989
« on: July 29, 2010, 04:25:38 am »
I couldn't find a pattern in Runner's corrupted data, it seemed to be completely random, but always a high order nibble indicating to me that it's most likely an error in reading the hexadecimal number since if one character gets accidentally read as a zero, that could cause it. My solution to this was to disable interrupts during all of the routines which swap pages (which is all the reading routines) because I fear that could be interfering. I have no idea if that solves the problem or not since I can't replicate it myself, I'll need some confirmation.
In DJ's case the corrupted app he sent me randomly had a zero written to exactly every 256th address, that is all addresses of the form $xxCE, and this isn't the data part of the code I'm talking about, this is the entire application and so some commands got screwed up due to having random zeros written over them. I'm not sure what this implies, but I think its possible that its a problem with the rom chip since the errors are so regular and the app itself compiled completely normally otherwise.
990
« on: July 28, 2010, 11:36:17 pm »
is the following code valid?
Copy(FlipH(L1),L1,8)
Yes, absolutely. Although this is theoretical syntax. I haven't even chosen tokens or names or even finished most of the routines.
Pages: 1 ... 64 65 [66] 67 68 ... 135
|
Show Posts