Sure the commands are the same, but the OSes are completely different in format and how things are run, not to mention hardware differences.
I have recently been trying to create a gui and whenever i do i suffer a calc crash the code i am using is:
Code:
Code:
DCSHDR0.HDR ; SAYS THAT I AM NOT USING ICON OR DESCRIPTION
START:
BCALL CLRLCDFULL
CALL OPENGUISTACK
LD HL,SMWINDATA
LD DE,SMWINDATAEND-SMWINDATA
LD A,GUIRSMALLWIN
CALL PUSHGUISTACK
CALL GUIMOUSE
RET
SMWINDATA:
.DB 5,5
.DB $F8,$88,$88,$88,$F8
.DB "MY WINDOW",0
SMWINDATAEND:
To quote [GUIMouse] from the DCS wiki:
Quote:
hl = Location of hook to call once per cycle. You must set this to $0000 if not using one. Hook Note: the current mouse location as (x,y) will be in (a,l) when the hook routine triggers. You can also get/set the location by checking in MouseX and MouseY. To force the GUIMouse to return control to your program from inside the hook, set the coordinates to an object that would cause it to exit anyway, and add an extra pop to the routine. if you have no suitable gui object you can use an offscreen GUIRHotspot, and set the mouse location to that.
Long story short: you need a ld hl,0 before you call GUIMouse. 
lafferjm wrote:
i added one and still could not get it to work.
What wouldn't work? Can you move the mouse around, or it crashes when you render the GUI?
Try also pushing some GUIRWinButtons onto the stack and see what happens. Try an [X], onclickable to somewhere directly after the GUIMouse call, and don't forget to ResetAppPage.
Alright i will try that later, but i still have a few questions. How would i keep track of multiple objects? And which flag to i have to set/reset to write text to the buffer?
I have another question to add to that list. How can i create a sufficient delay. I am trying to create a button mashing game but i cant get the program to run slow enough for you to push any buttons withing the timer. What i am using for a timer is loading hl with 65535 and then just decrementing it but it finishes in a couple seconds.
If i wanted to draw a sprite from a string could I just take the hex data from the string and store it by loading the data from str0 somewhere and then write to label by doing something like:
Code:
Also how would i get the data that was stored in str0.
Code:
ld hl,str0dat
ld (sprite),hl
call spriteput
...
sprite:
.db 0Also how would i get the data that was stored in str0.
You mean a string like this ("D66710029DEAB102")? Tokens for "0"-"9" start at 48 and letters start at 65. So, get the token #, subtract 48, and subtract 7 more if the number's still 17 or greater. Do RLCA 4 times, repeat the subtracting part with the next token, and add the RLCA'd number to the most recent token. Store it somewhere and move on to the next two tokens. That's the best way I can think of for getting from string-hex to the actual kind...
In asm in 28 days I was looking over the part about arrays because i wanted to start working on a tilemapping routine and i was wondering; how would i find out what the array_base and array_size were?
I haven't looked at this in about 3 years, so it can probably be uberoptimized, but here's how DCS does it:
Code:
Code:
dcsSquish: ;optimized - should still work
push bc
ld c,2
dcsSquishLoop:
call GetArcProgByte ;A=ascii 65d
push hl ;0=ascii 48d
push de
ld e,48d
sub e
cp 10h
jr c,dcsSquish_DONE
sub 7 ;save 5 bytes
dcsSquish_DONE:
pop de
pop hl
inc hl
dec c
jr z,dcsSquishNext
sla a
sla a
sla a
sla a
ld (ScratchVar),a
jr dcsSquishLoop
dcsSquishNext:
ld b,a
ld a,(ScratchVar)
or b
ld (de),a
inc de
pop bc
dec bc
ld a,b
or c
jr nz,dcsSquish
ret
Looking at your code, my algorithm was correct (besides your having used SLA instead of RLCA, which doesn't make much of a difference in this case). That makes me happy.
haveacalc wrote:
Looking at your code, my algorithm was correct (besides your having used SLA instead of RLCA, which doesn't make much of a difference in this case). That makes me happy.
I used sla because it drops 0's into right side instead of 1's. rlc a wouldn't work properly, but you did indeed have the correct idea.
But a would only hold a value between 0 and 15, since that's what would have been gotten from the token. The four most significant bytes should be reset already.
Other right, brilliant one. 
As it shifts left, it has to put something on the left, and rlc uses the carry. Chances are the carry might start out set in this instance, which would falsely add 8 to the final value.
As it shifts left, it has to put something on the left, and rlc uses the carry. Chances are the carry might start out set in this instance, which would falsely add 8 to the final value.
I was under the impression that RLC only copied to the carry and that RR was the one that shifted the old value of the carry to the least significant byte. I'm really not intending to correct you as much as trying to figure it out for myself...
Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement