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 - thepenguin77
Pages: 1 ... 35 36 [37] 38 39 ... 108
541
« on: October 12, 2011, 03:36:23 pm »
Of course I test it. I build the levels little bits at at time. The best part is that since I have only a label stating where the level actually starts, I can start halfway through a level to test the second half. This is how I made the newest level, during testing, I even had my screen facing the right way 
542
« on: October 11, 2011, 06:58:35 pm »
Just to clear things up. SMC is purely changing your code on the fly to do things more efficiently. You would typically want to do this in very time sensitive sections that get executed thousands of times per second. (i.e. bullet/enemy collision checks) The general idea is to setup the code with some "fairly constants", like the x/y of the enemy you are going to check against all 50 bullets, so that rather than pulling the x/y coordinates out of memory for all 50 bullets, they are hard coded into the routine. What does this mean for axe? Unless you know asm very well, and understand Axe to the level that you could compile programs yourself, you should not touch SMC. Now, what you are trying to do with copying your routines into appvars and using them later will not work in Axe. There are two reasons for this: 1) You can't execute the appVar where it lies because it is probably in the $C000 range and will insta-crash your calculator. 2) Axe code meant to be run at a certain memory address in the calculator and from a certain program. When compiling, Axe has to hard code in locations for it's internal routines (like ClrDraw) so that it can call them without crashing. And not only that, but the actual code itself has to call itself which means it has to be run from a very specific address in memory. If you just copy the back end off an axe program off and store it in an appvar. The only way to make it function would be to copy it back to the exact same spot in the exact same program. If you copy it back to any other address (any of the other 32,767 addresses) or in any other program (even a recompiled version might not work) the routine is going to crash. What can you do? Really, your only option for something like this is just to make your minigames into separate axe programs and have your main program call them. Or, you could always just put all the minigames into the same file 
543
« on: October 11, 2011, 03:09:50 pm »
As far as how far the player can jump, I already know those distances. These assume endless jumping (you land in the same spot you take off from). Also, each object, while 6 pixels wide, is only 3 frames wide so: Height Distance (from start of block) +2 3*3 +1 4*3 +0 4*3+2 -1 5*3 -2 5*3+1 And the standard fall off block is 3*3. However, as far as making the level editor, I don't know about that. It's quite a bit of work, and honestly, has anyone beaten the default levels yet? Edit: Oh, and just to let you know what the levels look like when I make them. This is what they look like: newLevel:
spike(0, 5*3)
spike(0, 7*3)
blockSingle(0)
commandWait(cToggleDark, 4*3)
block(1, 4*3)
block(2, 4*3)
block(3, 3*3)
block(2, 1*3)
spikeSingle(5) ;you have to block, else a shortcut is present
block(4, 2*3)
block(1, 3*3)
block(3, 4*3+1)
block(4, 4*3)
block(5, 5*3)
block(4, 1*3)
spikeSingle(7) ;again block is necessary
block(6, 2*3)
block(3, 3*3)
block(2, 3*3+1)
block(4, 3*3)
block(6, 3*3)
block(8, 1*3)
block(8, 1*3)
block(8, 1*3)
spikeSingle(9)
That's like the first 5 seconds of the new level. No fancy editor, and no fancy drawings. Just a line of numbers.
544
« on: October 10, 2011, 10:22:20 pm »
Oh, well, that's not really fast mode. Doing that will get you a 15% speed increase in the best case scenario, and that scenario is that you are running from flash in 15Mhz mode. Port ($2E) is actually just a delay port that TI added. What it does is it takes away the 1 t-states per read from flash delay that TI added. Furthermore, it's effects are only seen if you are running in 15 Mhz mode, it has no effect in 6Mhz mode. (Unless you do some other stuff. Check WikiTI for the full interaction between ports 29, 2A, 2B, and 2E.) This code however: ld a, 3
out ($20), a
Will make the calculator run 250% faster. This is all it takes to put the calculator into 15Mhz mode. In all honesty, you really don't even need your code. The only reason you might need it is if you are running a very time-sensitive app. But, since you know about it, you might as well zero port ($2E) anyways. Also, you are 100% allowed to leave port ($20) at 03 (default 00) because the OS is going to throw it in 03 when you return anyways. Leaving port ($2E) at 00 should be fine as well 
545
« on: October 10, 2011, 02:44:39 pm »
Yeah. I think I can handle that. How many 'nop' or 'halt' cycles would equal 1 second, in fast mode?
For nops, you need whole heck of a lot. Each nop takes 4 t-states. And you figure the median calculator is running at 15,500,000 t-states per second so... 3.7 million nops. If you want to use instructions to slow down your program, here's a routine you can use:
;hl = milliseconds of delay
milliDelay:
ld b, 174 ;7
innerLoop:
ex (sp), hl ;19*174 ;3306
ex (sp), hl ;19*174 ;3306
ex (sp), hl ;19*174 ;3306
ex (sp), hl ;19*174 ;3306
djnz innerLoop ;13*173+8 ;2257
dec hl ;6
ld a, h ;4
or l ;4
jr nz, milliDelay ;13
ret ;15,515
Halts work entirely different though. Halts wait for an interrupt and the interrupts run at a constant speed. That speed is 118 Hz on an 83+ and 107.79 Hz on everything else. But since you said you're running in fast mode, clearly you are not on an 83+ so you would need 108 halts to wait for one second. (I said "median" calculator up above because calculators run anywhere from 14.5 MHz to 17.0 MHz in fast mode)
546
« on: October 10, 2011, 12:18:25 pm »
uh, why would you need to kill on+mode?
It would kill on+mode in the program editor because my hook would always fire first. Yeah, I was using EF0850. And I have no idea what you said, so I don't know how to do it. Also, I want to do this in Axe. Thanks loads!
Here's the axe code: (the first time I've actually written serious axe code) :[83 3E 00 FD 77 34 21 00 00 22 88 9B 3E 00 32 8A 9B EF 08 50]->Str1
:Str1+19
:Asm(11 85 98 01 14 00 ED B8 FD 7E 34 32 74 98 2A 88 9B 22 79 98 3A 8A 9B 32 7F 98 EB 23 3E 01 EF 7B 4F)
Sorry for the asm explosion, but, I had no choice. Here's what the asm is doing: hook:
add a, e ;1
ld a, 0 ;2
ld (iy + $34), a ;3
ld hl, 0000 ;3
ld (getCSCHookPtr), hl ;3
ld a, 0 ;2
ld (getCSCHookPtr+2), a ;3
bcall(_powerOff) ;3
;20
asm:
ld de, appBackUpScreen+19
ld bc, 20
lddr
ld a, (iy + $34)
ld (appBackUpScreen+2), a
ld hl, (getCSCHookPtr)
ld (appBackUpScreen+7), hl
ld a, (getCSCHookPtr+2)
ld (appBackUpScreen+13), a
ex de, hl
inc hl
ld a, 1
bcall(_enableGetCSCHook)
I could have made it smaller, but the way it is now, it restores the hook that it kills.
547
« on: October 10, 2011, 10:53:14 am »
While I'm not necessarily going to write the routines for you (I've already written quite a few) here's how I would go about writing them: 1. I know my house might get bombed for this, but honestly, the only way I can see to do this would be to check out how Axe does it. Axe draws perfect circles very quickly and if I needed a circle routine, I would just copy axe's. 2. This one has actually been done for you, bcall(_DrawRectBorderClear) draws a rectangle with a white inner section. (Page 142 if your browser doesn't redirect you) 3. If you mean just draw text, then bcall(_vPutS) is your routine. But, if you mean draw text within a certain boundary area, bcall(_SFont_Len) will tell you how long an individual letter is. From there, you can draw the letters 1 by 1 with bcall(_vPutMap) and start a new line whenever you run out of space. (bcall(_SFont_Len) is on page 47 of that pdf I linked above) 4. There are so many sprite rendering routines, there's no need to make a new one. Here is a page for 8-bit wide sprites and here is a page for 16-bit wide sprites. However, if you want just a single routine to do all of your sprites no matter how big they are, this is your routine. Of course, picking one of the smaller ones would be faster than this though. As for the delays, your best bet is to make a single delay routine and call it. In all honesty this routine right here is probably all you need: Delay:
dec hl
ld a, h
or l
jr nz, delay
ret
548
« on: October 09, 2011, 11:28:10 pm »
That is the best. I thought that truvid was a joke, there is like no way for it to be as fast as in the video!
Missed it by like 2 weeks but wtf?
549
« on: October 09, 2011, 02:15:04 pm »
Ok, see, the thing is, at this time, I don't plan to make this app two pages. The transition to two pages would be about as big of a change as when I switched over to the new appvar system, which took me 20 hours. Normally, that wouldn't really be too bad for me, but, the problem is, I also have my new android phone which I need to program for. And one of the benefits of programming for my phone is that once I make some awesome apps, I'll have a consistent monthly income just for sitting at home programming. (Btw, I've already put in >1000 hours on zStart ) Let's say I want to make a password program with zstart. Am I correct to assume that the "run on start" thing is just like the start up app?
No, run on zStart is if you want to add an extension to the app, it's got a lot of rules and only runs when you quit the app/ram clear. The one you want is run on "Turning On", this functions exactly like start-up.
Ok, Is there any way to turn the calc off while running a program like that? Using an opcode crashes.
I assume that you are doing bcall(_powerOff)? (EF 08 50) You are right, this won't work very well at all. I know you're probably writing this in axe, but the best thing to do would be to make a getCSC hook, return back to zStart, and as soon as the calculator begins to run, the getCSC hook will kick in and from there you can turn off the calculator. (Tell me if you have no idea how to do this, I can probably set you up.) Ah! Find/replace was what I was gonna ask for next!
About the Undo:
4000 bytes is a little ridiculous for a line.
I have only had one source in my entire coding experience go over 4k, and that's because it consisted of gigantic walls of text. One source! I understand that sources can get a lot bigger, but the point I am trying to make is that, if you have one line that's 4000 bytes long, you really need to rethink your code, even if it's data; one keypress, and thousands of bytes of data are gone. What about halving it? Having half for the undo, and half for the clipboard.
Also, can we please have a button to quit the editor without saving? Or, better yet, have a button that brings up a menu of all the things zStart can do, and one option in that menu is to quit w/o saving.
You are right, there's isn't really much reason to reserve 4000 bytes for copy and paste, I'll cut that in half and give the rest to undo. Quitting without saving is also mind-numbingly simple for me. But now the real question, what should the shortcut keys be for these? Does undo = [on] + [^] and quit without saving = [on] + [del] sound good? ([on] + [mode] is also an omnicalc shortcut, so I hate to permanently kill it) I don't think it was removed.
Source: 5 sec ago
It was. Source: I deleted the code.
550
« on: October 09, 2011, 11:34:30 am »
also, is the upside- down at 90 attemps also on purpose?
No, that's a bug, I still have no idea what causes it.
551
« on: October 09, 2011, 11:11:06 am »
I found a bug in the most recent version posted on this thread, the one where you have to press GRAPH to play the new level. You can press Y= or WINDOW to get the first/second level but just upside down.
Or I did that on purpose. It's here to stay.
552
« on: October 08, 2011, 07:38:57 pm »
calc84's is broken as far as I can tell because it neglects that when "duplicated" A is two bytes. (You also need to 256-byte align the table.)
I thought that same thing at first, however: inc h
He actually did it right. He just didn't order the LUT the way you expected him to (Or for that matter, the way any other person would.)
553
« on: October 08, 2011, 05:03:09 pm »
Yep, I asked buckeye about this a while ago. Debugger>Tools>Code counter. Activate it, run your code, the click it again to see how many t-states were elapsed.
554
« on: October 08, 2011, 05:01:26 pm »
Is there any chance of a "checkpoint" sort of thing? Not having one is what makes it so much fun and so frustrating 
Indeed. Seconded. It would actually not be cool if you had chackpoints.
Exactly, checkpoints, in normal mode, would completely ruin the game. The idea is that you have to keep starting over and replaying it. It's the same reason that Guitar Hero II - Jordan is so hard, you have too keep playing the one minute intro before you even get a chance to tackle the hard part. The regular game has a practice mode where you set breakpoints. Now, personally, I don't like it. I think it takes away from the game. But, when you're playing on an iPod, the reason you don't want to use practice mode is because practice mode music sucks. Since I can't make practice mode have bad music like that, I did not include it in the calculator version either.
555
« on: October 08, 2011, 04:56:15 pm »
Let's say I want to make a password program with zstart. Am I correct to assume that the "run on start" thing is just like the start up app?
No, run on zStart is if you want to add an extension to the app, it's got a lot of rules and only runs when you quit the app/ram clear. The one you want is run on "Turning On", this functions exactly like start-up. I just came up with an idea:
An Undo button.
So, so many times I've accidentally pressed the wrong keys and deleted a line I didn't mean to.
Can this be done, plz?
Or, at the very least, can there be a hook installed that logs the contents of a line when an action is performed that overwrites it, like pressing the CLEAR key or 2nd RECALL
That would be super handy! I have cleared "pages" of sprite data with on keypress 
It wouldn't be that difficult to do, however, it would have to interfere with copy/paste. If you cleared a line, it would then go to the clip board. So while I like the idea of undoing, I think leaving copy/paste as a powerful solution is the best plan of action. The reason I can't do both is purely due to memory constraints, (like physical ram). This is prolly too big to be in the app, but how about a find/replace? Is the program editor too unfriendly and/or poorly coded to handle it?
That's totally possible. I can see a little trouble with actually displaying the whole line that the search word is in, but it should be doable. However, when I say doable, this would be >2KB worth of code, so...
Pages: 1 ... 35 36 [37] 38 39 ... 108
|
Show Posts