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 - Jerros
Pages: 1 ... 5 6 [7] 8 9 10
91
« on: August 04, 2010, 02:56:55 am »
Yes, calls can be conditional. They can also use all the conditions not just z nz c nc. Like m for negative or p for positive.
Also, you only need one inc hl after you write a variable to memory. That's because A is one byte, ld (hl), a stores one byte, so you only need to increase one byte. If you have a bigger number to store, you have to split it into bytes. So DE is stored E then D.
Calls can be conditional.... Ok, now I got to optimize like 2000 lines >.< Great to know though. Also, thanks alot for the "cp hl" routine, I used a routine that splitted the 16-bit numbers and then compared the seperate 8-bit registers, which is much much longer. And I know now that one inc of HL is enough, thought that if I'd store a large number it would automatically write two bytes, untill I figured that you can't actually do that. Wel... one again you've all amazed me, and left me without any questions. Thank you, Thepenguin!
92
« on: August 03, 2010, 10:43:57 am »
I'm now using an modified version of what Thepenguin posted.
It seems to work great, though I deleted some lines of which I didn't knew what they did, so there's probably something wrong, but as long as it works I'll just stick to that:
;To create if none exists, and unarchive if it does:
ld hl, "NameOfAppVar"
rst 20h
bcall(_chkFindSym)
jr nc, found
ld hl, "random size"
bcall(_createAppVar)
JR Programm
found:
ld hl, "NameOfAppVar"
rst 20h
bcall(_chkfindsym)
ld a, b
or a
bcallnz(_arc_unarc)
Programm:
....
....
....
;And archiving it again upon exiting
quit:
ld hl, CHData
rst 20h
bcall(_chkfindsym)
ld a, b
or a
bcallz(_arc_unarc)
b_call _JforceCmdNoChaR
;To store numbers:
ld hl, "NameOfAppVar"
rst 20h
bcall(_chkFindSym)
inc de
inc de
ex de, hl
ld a, "Number to be stored"
ld (hl), a
inc HL
inc HL ;whatever many times needed, depending on the size of the previous number stored
inc HL
ld a, "Another number to be stored"
ld (hl), a
; ect ect ect
;
; To read from the Var, I use the same lines as the "To store numbers:" part, just switch around (hl) and a.
While I'm at it, when doing Hi-Scores, you obviously must compare the currend score with the hi-score, and save the new high-score if it's higher (duh).
Now you guys helped me figure out the hard part, reading the old score and possibly writing the new one, but... what's the best routine for comparing two 16-bit numbers and jump to lbl1 if it's lower or to lbl2 when higher?
Can you just sub two 16-bit registers and check if the outcome is "negative" or not?
Ohh, and another one: Cann you do the CALL command with a condition?
cp 3
call z, label
And yes I'm THAT big of a newby...
93
« on: August 03, 2010, 03:06:43 am »
Ok, I'll try that, though I must admit I still dont understand all of it. But after messing around for a couple of hours I should get the hang of this. Thank you! ld (hl), a
inc hl
ld (hl), b
inc hl
ld (hl), c
inc hl
ld de, (score)
ld (hl), e
inc hl
ld (hl), d
So, are a, b, and c just 1 byte numbers I want to save, or the registers? ><
94
« on: August 02, 2010, 02:48:35 am »
@Jerros, here is a nice routine to get you to the start of the appVar. It will create it if it doesn't exist, and it will unarchive it if it's archived.
getAppVar:
ld hl, appVarName
rst 20h ;move9ToOp1
bcall(_chkFindSym)
jr nc, found
ld hl, size
push hl
bcall(_createAppVar)
inc de ;skip size bytes
inc de
ex de, hl
pop bc
bcall(_clearMem) ;fills hl with bc 0's
jr getAppVar
found:
ld a, b
or a
jr z, inRam
bcall(_arc_unarc)
jr getAppVar
inRam:
inc de
inc de
ret
appVarName:
.db appVarObj, "appVar", 0, 0
; 15h
Just be sure to archive it when you program quits.
Yay! Thanks, I'll mess around with this today, if I stumble across any problems I'll post that here. I hope I get the hang of this fast, then I can release my game : ) EDIT: bcall(_createAppVar)
bcall(_clearMem) ;fills hl with bc 0's
Erm... you mean b_call _Memclear? ClearMem doesn't get reconized by my assembler, and using b_call _MemClear will just crash the calc. Also, just removing that line will crash the lot too  getAppVar:
ld hl, CHData
rst 20h
bcall(_chkFindSym)
jr nc, found ; AppVar exists
ld hl, 500 ; Size of AppVar, random.
bcall(_createAppVar)
JR RestOfProgramm
found: ; Unarchive if not already
ld hl, CHData
rst 20h
bcall(_chkfindsym)
ld a, b
or a
bcallnz(_arc_unarc) ;only unrchive if not already in RAM
jr RestOfProgramm
CHData:
.db appVarObj, "CHData ", 0, 0
RestOfProgramm:
...
...
...
quit:
ld hl, CHData
rst 20h
bcall(_chkfindsym)
ld a, b
or a
bcallz(_arc_unarc)
b_call _JforceCmdNoChaR
The above is what I'm doing now and works. It creates an AppVar if none exists already, and unarchives it if it's archived. Also Archives it again upon exiting. Though I'm still not sure on how to store/recall data from it. Also, I just took an arbitrary size, I don't know how much is needed (just some numbers between 0-9999 won't take up much I suppose...).
95
« on: August 01, 2010, 08:35:24 am »
So my game is as good as complete, the last thing I must do is to be able to permanently save data.
I've read the AppVar part in Developpers Guide, but I just lack the knowledge to comprehend it all.
My question remains: How do I store simple data (just numbers, that's all) so that it can be recalled the next time someone runs the App?
All I really want is things like:
Hi-Score:
.db 496
Achievements:
.db 1
Whatever:
.db 9999
but then to be saved after the programm is exited, and able to recall later on.
Would be perfect if the AppVar gets archived when the programm is closed, but that part shouldn't be hard and I can figure that out myself.
So... anyone has an easy way to save/recall numbers in Apps?
96
« on: July 27, 2010, 09:55:06 am »
Wow, thank you alot! I don't think I can use the second routine though, it's a timing-game where you have to press button(s) according to when a sprite is in a certain area, so it needs to respond as soon as you press the button. But that "timing window" in the first routine sounds perfect, allows me to try and see what's enough time to react to multiple buttons pressed, but not waiting too long for it to feel inresponsive. Oh, and I know its always better to use "JR", but my jumps are out of range, so... EDIT: Ok this sucks... somehow there's something wrong in the rest of my script, since what you've both posted works... It wasn't even necasery to perform a diferenct scrip when multiple buttons are pressed, just do the routine of 1 button, and then the other. But somehow my routine fails, I've re-wrote it several times already, but this just doesnt seem to happen for me >< It has probably something to do with the massive routines it performs when a button is pressed, I don't know. Let the long hours of going over every line begin. :'(
97
« on: July 27, 2010, 08:11:22 am »
Its possible, but its only a byte more with negligible speed difference, I would go for the extra safety because the downside is so small and if it spares you from a gruesome hour long debugging session in the future it will have all been worth it.
Ok, went for the extra safety... Another thing, your provided script works like a charm, as long as I only use it to regiser a single button press. When I press multiple buttons, the script get performed the whole time again, and not just once 'till I've released the buttons again: ld a,(MyKeyVariable)
or a
jr nz,CheckForRelease
LD A, %10111111
OUT (1), A
ld b,%11101101
IN A, (1)
CP %11101111
JP Z, presyequ
CP %11110111
JP Z, preswindow
CP %11111011
JP Z, preszoom
CP %11111101
JP Z, prestrace
CP %11111110
JP Z, presgraph
; The above all works perfect with your routine, but the below doesn't:
CP %11100111
JP Z, presyequ_window
CP %11101011
JP Z, presyequ_zoom
CP %11101101
JP Z, presyequ_trace
CP %11101110
JP Z, presyequ_graph
CP %11110011
JP Z, preswindow_zoom
CP %11110101
JP Z, preswindow_trace
CP %11110110
JP Z, preswindow_graph
CP %11111001
JP Z, preszoom_trace
CP %11111010
JP Z, preszoom_graph
CP %11111100
JP Z, prestrace_graph
jr LabelRestoftheScript
CheckForRelease:
xor a
out ($01),a
ld a,(de)
in a,($01)
inc a
ld (MyKeyVariable),a
LabelRestoftheScript:
stuf.....
Is the problem in the "presXXX" labels, or is there a different reason it just keeps performing the labels combining multiple keys? Also, I should've probably mentioned that it sometimes does seem to work, but when you press multiple keys for a while, or just keep 1 button pressed down and change the other the lot gets messed up :c
98
« on: July 26, 2010, 03:49:15 am »
Normally, you don't notice the lack of delay because the first time it passes that part in the program, it has the wrong key group when it tries to read the key, but its set correctly afterward once it finally goes through. The time you will notice it is if you check a bunch of keys one after another from different key groups. Then, each check you do is reading from the previous keygroup, which is wrong and you end up with mismatched keys.
Aha, well I'm only checking one group, so it won't be a problem to skip the delays, will it?
99
« on: July 26, 2010, 03:02:23 am »
Also, you need at least a 7 clock cycle delay between setting the key groups and reading their values because the hardware is slow and otherwise it will read values of the previous key group and can cause weird things to happen.
Ye, I've read all about that. I'm not doing it now though, and everything still works fine, but if its better to add the delay I will.
ld b,%11101101 ;This is a delay before reading the key groups. Does something useful.
ld a,(de) ;Another delay
The thing is, I need this routine to be as fast as possible, is anything noticable about the delays? Or is it lightning speed, just as the rest : ) Thanks alot, I knew there had to be something like this, just didn't knew what. n_n I'll try your routine later today.
100
« on: July 25, 2010, 10:37:05 am »
Ok, so I know there are several ways to check the key(s) that is/are being hold down, but as far as I know there's only 1 way to check for multiple keys:
LD b, 4 ; whatever many times the loop is executed
loop:
LD A, %11111111 ; group
OUT (1), A
IN A, (1)
CP %11101101 ; whatever key(s) you wanna check for
JR Z, Label ; if the keys you were checking for were pressed, JP to label
djnz loop
Works like a charm, in fact, works a bit TOO well; if I keep the correct button(s) down it jumps to "Label" several times per loop. (or each loop, hard to see)
Now, If you'd use the standart:
LD b, 4 ; whatever many times the loop is executed
loop:
b_call _GetCSC
CP sk2nd ; whatever key you wanna check for
JR Z, Label ; if the keys you were checking for were pressed, JP to label
djnz loop
instead of the first, then there's just 1 jump to label if you hold the button down, BUT it cant check for multiple keys being pressed or not.
Is there a way to both check for multiple keypresses but only jump once untill you release the buttons and press them down again?
I hope I've made myself clear, its hard for me to explain :O
Thanks in advance!
101
« on: July 13, 2010, 03:48:36 am »
uit mijn hoofd doe zou ik dit doen:
ypos .equ AppBackUpScreen
xpos .equ AppBackUpScreen+1
clip_mask .equ AppBackUpScreen+2
LD A, 38
LD (xpos), A
LD A, 54 ; Y position do display
LD (ypos), A
LD B, 9 ; Length of Sprite in Y direction
LD D, (xpos) ;ik weet niet of D =ypos of E=ypos maar je kan het altijd nog omdraaien
LD E, (ypos)
LD IX, Sprite ; Label of sprite
CALL showsprite
ik weet dus niet of dit werkt maar in ieder geval moet het probleem wel duidelijk zijn nu...
Yay! All I had to do was switch around xpos and ypos in the .equ part, didn't had to change anything else. this is an example of something so small that I would never had found it without your help. Oh, and doing LD D, (xpos)
LD E, (ypos)
can't, since I just load Ypos into DE, not Xpos. (check the first post) And I don't think its nessecary to do ypos .equ AppBackUpScreen
xpos .equ AppBackUpScreen+1
clip_mask .equ AppBackUpScreen+2 ; Dont think the +2 is needed, because I justdo this:
ypos .equ AppBackUpScreen
xpos .equ ypos+1 ;I just do the previous statement +1, that doesn't result in errors (I think), because
clip_mask .equ xpos+1 ;I've even done +9 while the script wasnty working, and it still kept failing
Thanks alot! This was one of the last hurdles to complete the programm, just 1 more thing to tacke but I'll ask (if needed only ofcource) that in another topic. (It's about permanently saving hi-scores/variables ect. in the archive in an APP) Really, big thanks for all the help here. 
102
« on: July 12, 2010, 01:19:07 pm »
I really need glasses...
It is indeed at the place I meant it to be, sorry for any confusion caused.
103
« on: July 12, 2010, 01:11:42 pm »
Dang, I just realize I'veposted in the wrong place on the forums...  Sorry! About your reply, It has always worked before, before I turned it into an App, or is it failing now because of the .equ's at the start? I should have mentioned that I'm a biggg newby at ASM... Where do I need to switch the two around? In the defining part at the start? If you can please explain just a little what's wrong, then I perhaps understand it and can prevent similar mistakes in the future. Is there an order in the defining part if I want to define lots of things? Thanks alot for your reply, I'll look into it and hope I can fix it!
104
« on: July 12, 2010, 09:22:44 am »
I'm using the routine from the asm-in-28 tut, though the sprites display blurry and at the wrong coordinates.
The part of the "ClipSprXOR" label should be OK, since it's just copy/pasted from the tut, and it worked 100% fine before I turned the programm into an APP.
The routine I'm using to display sprites in an APP is:
(used random location and sprite, for exemple's sake)
xpos .equ AppBackUpScreen ; To prevent SMC
ypos .equ xpos+1 ; Tried +2 and even +9, don't know wether that makes a difference
clip_mask .equ ypos+1 ; or not, but just to be sure. It didn't work though...
LD A, 38 ; X position to display
LD (xpos), A
LD A, 54 ; Y position do display
LD (ypos), A
LD B, 9 ; Length of Sprite in Y direction
LD DE, (ypos)
LD IX, Sprite ; Label of sprite
CALL showsprite
Showsprite: ; Show Sprite (XOR)
CALL ClipSprXOR
b_call _GrBufCpy
ret
ClipSprXOR: ; Show Sprite XOR
LD A, %11111111
LD (clip_mask), A
LD A, E
OR A
JP M, ClipTop
SUB 64
RET NC
NEG
CP B
JR NC, VertClipDone
LD B, A
JR VertClipDone
ClipTop:
LD A, B
NEG
SUB E
RET NC
PUSH AF
ADD A, B
LD E, 0
LD B, E
LD C, A
ADD IX, BC
POP AF
NEG
LD B, A
VertClipDone:
LD C, 0
LD A, D
CP -7
JR NC, ClipLeft
CP 96
RET NC
CP 89
JR C, HorizClipDone
ClipRight:
AND 7
LD C, A
LD A, %11111111
FindRightMask:
ADD A, A
DEC C
JR NZ, FindRightMask
LD (clip_mask), A
LD A, D
JR HorizClipDone
ClipLeft:
AND 7
LD C, A
LD A, %11111111
FindLeftMask:
ADD A, A
DEC C
JR NZ, FindLeftMask
CPL
LD (clip_mask), A
LD A, D
ADD A, 96
LD C, 12
HorizClipDone:
LD H, 0
LD D, H
LD L, E
ADD HL, HL
ADD HL, DE
ADD HL, HL
ADD HL, HL
LD E, A
SRL E
SRL E
SRL E
ADD HL, DE
LD DE, PlotSScreen
ADD HL, DE
LD D, 0
LD E, C
SBC HL, DE
AND 7
JR Z, _Aligned
LD C, A
LD DE, 11
_RowLoop:
PUSH BC
LD B, C
LD A, (clip_mask)
AND (IX)
LD C, 0
_ShiftLoop:
SRL A
RR C
DJNZ _ShiftLoop
XOR (HL)
LD (HL), A
INC HL
LD A, C
XOR (HL)
LD (HL), A
ADD HL, DE
INC IX
POP BC
DJNZ _RowLoop
RET
_Aligned:
LD DE, 12
_PutLoop:
LD A, (IX)
XOR (HL)
LD (HL), A
INC IX
ADD HL, DE
DJNZ _PutLoop
RET
Sprite:
.DB %00011000
.DB %01111110
.DB %01111110
.DB %11100111
.DB %11100111
.DB %01111110
.DB %01111110
.DB %00011000
.DB %00011000
Doesn't work properly.
Where's my mistake?
Or is this just a wrong way of trying to display the sprites?
Thanks for any help!
105
« on: July 12, 2010, 06:22:47 am »
Thanks, using "b_call _JforceCmdNoChaR" fixed it, though I could SWEAR I've tried that already, else I wouldn't post it here...
Anyway, seems to work allright now, thanks alot!
Pages: 1 ... 5 6 [7] 8 9 10
|
Show Posts