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 - chickendude
Pages: 1 ... 14 15 [16] 17 18 ... 55
226
« on: June 13, 2014, 10:01:26 am »
Wow those were fixed fast! If you want, i can take some animated screenshots for the 83+ version (i don't have a CSE). The game is surprisingly fast, though, nice work 
227
« on: June 12, 2014, 11:03:15 am »
I just died on level 7 (with the T that shoots periods) and when i got sent two rooms back (LV.B? Just before the Z-shooting P) where you have to walk towards the A, the screen wasn't cleared and the T and two dots were still there. Not a big deal, just thought you might want to know. Otherwise it's really nice, though i have to say that the spaced text is a bit odd  It might look better centered. You can also hit the B's with your sword and it'll disappear (or at least in LV.7), at first i was afraid that i'd destroyed it  Another thing you can do is quit on LV.8 and pick up a lot of 1-ups. I guess the max is 10. Later when you die it looks like you've got 90, 80, 70, etc. And like DJ, the first boss was hard. I guess you've got to just keep moving, but it's hard to see their bullets. I think i just beat it, was the last level the one with the two M's? They didn't move or anything, so i'm not sure, but it just said i beat the game. It was fun, though a bit confusing at times. Nice job
228
« on: June 12, 2014, 09:35:46 am »
That's what i've been doing, it just takes a long time when you start having a lot of sprites, especially if you decide to move anything around. If you could copy the entire sprite data at once (like with the tilemaps) that'd solve it, too.
229
« on: June 08, 2014, 10:50:31 am »
Reuben also just has one moving object on the screen And at least the latest version runs perfectly fast, i think it jumps 4 pixels at a time and at that speed you can't really notice any slowdown.
230
« on: June 08, 2014, 12:29:03 am »
ExecAns shouldn't create a program, it runs a program. It takes the code in Ans, puts it into prgmU, and runs prgmU. The problem might be that the current running program (the one that calls prgmEXECANS) gets overwritten when prgmU gets run. I'm not sure, i'll look at it later. But this isn't really about writing assembly in hex anymore, you might want to open a new thread asking for help on this specific program. But it would really help if you provided the mnemonics instead of the hex so people other than Xeda and perhaps calc84maniac actually knew what the code did. Hex is such a pain. ;(saferam1 = saveSScreen)
name_str = saferam1
size = saferam1+2
code_start = saferam1+4
start:
bcall(_RclAns) ;set pointer into OP1
cp 4
ret nz
ld hl,$55 ;ASCII for 'U'
ld (name_str),hl ;save zero terminated string name
ld (OP1+1),hl
ld hl,code_start
ex de,hl ;de = code_start, hl = ans ptr?
ld c,(hl) ;i assume bc = size of Ans
inc hl
ld b,(hl)
inc hl
ld (size),bc
ldir ;copy code in Ans into saferam
bcall(_ChkFindSym)
jr c,not_found
bcall(_DelVarArc) ;del prgmU if it existed
not_found:
ld a,5 ;5 = non-protected program
ld hl,saferam1
bcall(_ExecuteNewPrgm) ;a = var type, hl = pointer to structure (zero terminated string, size (word), program data)
retA couple things: i'm not sure if RclAns actually gives readable results in a/de/hl. They seem to assume that _RclAns puts out the same outputs as _ChkFindSym (see WikiTI). WikiTI and the 83 Plus System Routines manual both say all registers are destroyed (ie. return junk/non-useful info). I don't know what happens with _ExecNewPrgm, it may kick the currently running BASIC program out. EDIT: If all you want to do is create a program, you should look at the _CreateProg bcall.
231
« on: June 07, 2014, 04:00:17 pm »
Looks good to me, for the menu what about having a little tongue come out or something when you select an option that swallows the word? I think the words could be a little closer to the lily pads, too. It looks pretty, though. It also seems like you've got the main body of the game done
232
« on: June 06, 2014, 06:00:57 pm »
Yeah. It's in hex codes. It'd be easier to help if you wrote them out in assembly mnemonics. The last line is a C9, the hex for "ret". But i don't know what you mean by "return" and not "stop". In assembly that's the same thing, quitting the program just means that there was nothing left on the stack. Do you understand what that program does?
233
« on: June 06, 2014, 09:24:04 am »
Yep, i didn't even notice that they'd changed my +. About the keys, i figured that you'd made it that way on purpose, but i thought it'd be nice to have a slight delay (like when holding the arrows down with _GetKey) before moving the angle again as i like to just use the two buttons when i'm already relatively close
234
« on: June 06, 2014, 06:23:42 am »
That's true, though i think seeing that the player's changed position would indicate that you've changed to a different screen. Really the idea is just to reduce loading times between screens a little.
235
« on: June 05, 2014, 06:55:59 pm »
Great, it works now thanks! And this is great! It would be nice if you could hold [sto] or [ + ] rather than press and release to move it, but i like the idea of using all those keys to select an angle. It'd be nice too if turning the other direction flipped your angle rather than resetting it to 90º. It'd also be nice if there were a button you could hold to view more of the map, for example pressing and holding [XTØn] and then being able to move the camera freely with the arrow keys. Letting go of the button would slide the camera back to it's normal position around the character. Also, [Mode] seems to leave artifacts behind when you move the worm, though i assume that's either a debugging thing or something not finished yet since it's not mentioned in the readme Anyway, great work, Matrefeytontias 
236
« on: June 05, 2014, 06:44:12 pm »
You don't even need to erase it, though, since Output( should overwrite what was there. So you can just draw the new map over top the old one and avoid the ClrHome and outputting spaces.
237
« on: June 05, 2014, 06:37:44 pm »
What do you mean? In assembly, ret ($C9) just jumps to the last address on the stack. If you have nothing on the stack (just what was on there from the OS when it ran your program) then it will return execution to the OS. Otherwise it will return from a call or to whatever you've put on the stack. You should really just learn the mnemonics which will help you with the basics of assembly. If you want to program oncalc, use Mimas or ASMDREAM.
238
« on: June 05, 2014, 02:59:36 pm »
t tried sending it to my 84+ but get a signature error for the app 
239
« on: June 05, 2014, 02:00:10 pm »
I was just wondering if it wouldn't be faster if you just updated the map rather than clearing the screen and redrawing everything. Output( should overwrite whatever's there anyway. EDIT: Just wanted to add that it's looking great
240
« on: June 04, 2014, 02:05:52 pm »
You could use appbackupscreen and gradually draw a ring around it. Just OR the gbuf with the corresponding byte in appbackupscreen (i dunno if your grayscale routine uses this as the second buffer, if it does just _InsertMem 768 bytes at the end of your program). It'll maybe cause a bit of slowdown but i don't think it'd be too bad, an extra 7 states for the OR statement (assuming your ORing it with (hl)) and another 15 t-states for the extra add statement (and maybe an extra 8 t-states if you've got to switch to shadow registers) in the main loop, but a lot of that can replace the wasted cycles if there are any in your grayscale code (i've never used grayscale, so i don't know what the fastcopy routine tends to look like).
Pages: 1 ... 14 15 [16] 17 18 ... 55
|
Show Posts