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 - matthias1992
421
« on: July 03, 2010, 12:43:02 pm »
Cool! BUt this also means that teh greater the amount of buildings the slower it will run right? I mean it is inevitable to have slowdowns but seemingly by this new approach you ahve reduced them to a minimum. How much buildings will it take until it is unplayable? And how much memory is used currently?
422
« on: July 03, 2010, 12:11:39 pm »
And here is yet another problem, I am trying to make this in a manner that every time + is pressed the next sprite is drawn and every time I press - the previous one is drawn. C is the counter of the sprites and checked if it is z, if it is the program is aborted (becuase you can't do -1 sprite) and if it is >255 9the maximum of 8 bits) it should also be aborted. P.s. I know C is already used elsewere, that is likely to screw it up but i tried to insert a cntr byte by doing:
cntr: .db 0 but then every time I did this:
LD cntr, C or this
LD (cntr), C it threw a error saying: "unrecognized argument"
This is my source:
.nolist #include "ti83plus.inc" #define ProgStart $9D95 .list .org ProgStart - 2 .db t2ByteTok, tAsmCmp ypos: .DB 0 xpos: .DB 0 clip_mask: .DB 0 B_CALL(_RunIndicOff) B_CALL(_GrBufClr) LD C, $0001 PUSH BC Show: CALL PutSpr B_CALL(_GrBufCpy) KeyLoop: LD A, $FD OUT (1), A IN A, (1) CP %10111111 RET Z CP %11111101 JP Z, NextSpr CP %11111011 JP Z, PrevSpr LD A, $FE OUT (1), A IN A, (1) CP %11111110 JP Z, MoveDown CP %11111101 JP Z, MoveLeft CP %11110111 JP Z, MoveUp JR NZ, KeyLoop ; Move sprite right CALL PutSpr ; Erase sprite LD HL, xpos INC (HL) JR Show ; Draw sprite at new location MoveLeft: ; Move sprite left CALL PutSpr LD HL, xpos DEC (HL) JR Show MoveUp: ; Move sprite up CALL PutSpr LD HL, ypos DEC (HL) JR Show MoveDown: CALL PutSpr LD HL, ypos INC (HL) JR Show NextSpr: POP BC LD A, C OR A RET Z CP 255 RET Z INC C CALL PutSpr PrevSpr: POP BC LD A, C OR A RET Z CP 255 RET Z DEC C CALL PutSpr PutSpr: PUSH BC LD DE, (ypos) LD A, C CP 1 LD IX, Spr1 CP 2 LD IX, Spr2 LD B, 8 ClipSprXOR: ; D = xpos ; E = ypos ; B = height ; IX = image address ; Start by doing vertical clipping LD A, %11111111 ; Reset clipping mask LD (clip_mask), A LD A, E ; If ypos is negative OR A ; try clipping the top JP M, ClipTop ; SUB 64 ; If ypos is >= 64 RET NC ; sprite is off-screen NEG ; If (64 - ypos) > height CP B ; don't need to clip JR NC, VertClipDone ; LD B, A ; Do bottom clipping by JR VertClipDone ; setting height to (64 - ypos) ClipTop: LD A, B ; If ypos <= -height NEG ; sprite is off-screen SUB E ; RET NC ; PUSH AF ADD A, B ; Get the number of clipped rows LD E, 0 ; Set ypos to 0 (top of screen) LD B, E ; Advance image data pointer LD C, A ; ADD IX, BC ; POP AF NEG ; Get the number of visible rows LD B, A ; and set as height VertClipDone: ; Now we're doing horizontal clipping LD C, 0 ; Reset correction factor LD A, D CP -7 ; If 0 > xpos >= -7 JR NC, ClipLeft ; clip the left side CP 96 ; If xpos >= 96 RET NC ; sprite is off-screen CP 89 ; If 0 <= xpos < 89 JR C, HorizClipDone ; don't need to clip ClipRight: AND 7 ; Determine the clipping mask 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 ; Determine the clipping mask 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 ; Set xpos so sprite will "spill over" LD C, 12 ; Set correction HorizClipDone: ; A = xpos ; E = ypos ; B = height ; IX = image address ; Now we can finally display the sprite. 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 ; Correct graph buffer address LD E, C ; if clipping the left side SBC HL, DE ; AND 7 JR Z, _Aligned LD C, A LD DE, 11 _RowLoop: PUSH BC LD B, C LD A, (clip_mask) ; Mask out the part of the sprite AND (IX) ; to be horizontally clipped 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 Spr1: .DB %10000001 .DB %11000011 .DB %01100110 .DB %00111100 .DB %00111100 .DB %01100110 .DB %11000011 .DB %10000001 Spr2: .DB %11111111 .DB %10000001 .DB %10000001 .DB %10000001 .DB %10000001 .DB %10000001 .DB %10000001 .DB %11111111 .end .end
423
« on: July 03, 2010, 11:36:08 am »
Well I do not dislike UTI. It is a valuable resource but it is to inactive for me. I don't like to wait a week before I get a answer...but that is just me being inpatient.
As for .ocx and DLL's these are not needed. It will eventually be packedinto one exe file. The only prerequisite is the latest Windows Runtime .NET© (or something like that, I forgot it's exact name) but when you make a exe in VB2008 it automatically whil check if you have the latest Runtime version installed an warn you if you haven't. Most people who use third party software or any other microsoft software besides windows will already have this installed.
I'll (no promise) post a image of the GUI here soon.
424
« on: July 03, 2010, 10:50:40 am »
I don't think backing up the OS is NOT
a) useful b) possible
You could backup all the system flags and entry points and you could possibly make a "snapshot" of the machine's state (as the restore point). Compression techniques will be have to put to their limits to get all the information sqeeuzed in and then yet there is the question hw useful it is. Saving the current state of the machine as I mentioned earlier seems more useful. You would store all the current programs, apps, appvars, user vars, system flags etc. And you'd backup all the registers. That should/might fit into Flash and it would be enough to recover from a RAM clearance (but then again groups will do that as well).
425
« on: July 03, 2010, 10:43:56 am »
hey there!
I slightly modified the spirte routine from Ti asm in 28 days to support hardware keycode control. The point is if i wanted to display a 16x16 sprite (x,y) then what should I change? I do understand how to make a (8x#) sprite, you just need to modify B for that but how can I make the sprite wider?
Thanks in advance!
.nolist #include "ti83plus.inc" #define ProgStart $9D95 .list .org ProgStart - 2 .db t2ByteTok, tAsmCmp B_CALL(_RunIndicOff) B_CALL(_GrBufClr) Show: CALL PutSpr B_CALL(_GrBufCpy) KeyLoop: LD A, $FD OUT (1), A IN A, (1) CP %10111111 RET Z LD A, $FE OUT (1), A IN A, (1) CP %11111110 JP Z, MoveDown CP %11111101 JP Z, MoveLeft CP %11110111 JP Z, MoveUp JR NZ, KeyLoop ; Move sprite right CALL PutSpr ; Erase sprite LD HL, xpos INC (HL) JR Show ; Draw sprite at new location MoveLeft: ; Move sprite left CALL PutSpr LD HL, xpos DEC (HL) JR Show MoveUp: ; Move sprite up CALL PutSpr LD HL, ypos DEC (HL) JR Show MoveDown: CALL PutSpr LD HL, ypos INC (HL) JR Show ypos: .DB 0 xpos: .DB 0 sprite: .DB %10000001 .DB %11000011 .DB %01100110 .DB %00111100 .DB %00111100 .DB %01100110 .DB %11000011 .DB %10000001 PutSpr: LD DE, (ypos) LD IX, sprite LD B, 8 ClipSprXOR: ; D = xpos ; E = ypos ; B = height ; IX = image address ; Start by doing vertical clipping LD A, %11111111 ; Reset clipping mask LD (clip_mask), A LD A, E ; If ypos is negative OR A ; try clipping the top JP M, ClipTop ; SUB 64 ; If ypos is >= 64 RET NC ; sprite is off-screen NEG ; If (64 - ypos) > height CP B ; don't need to clip JR NC, VertClipDone ; LD B, A ; Do bottom clipping by JR VertClipDone ; setting height to (64 - ypos) ClipTop: LD A, B ; If ypos <= -height NEG ; sprite is off-screen SUB E ; RET NC ; PUSH AF ADD A, B ; Get the number of clipped rows LD E, 0 ; Set ypos to 0 (top of screen) LD B, E ; Advance image data pointer LD C, A ; ADD IX, BC ; POP AF NEG ; Get the number of visible rows LD B, A ; and set as height VertClipDone: ; Now we're doing horizontal clipping LD C, 0 ; Reset correction factor LD A, D CP -7 ; If 0 > xpos >= -7 JR NC, ClipLeft ; clip the left side CP 96 ; If xpos >= 96 RET NC ; sprite is off-screen CP 89 ; If 0 <= xpos < 89 JR C, HorizClipDone ; don't need to clip ClipRight: AND 7 ; Determine the clipping mask 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 ; Determine the clipping mask 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 ; Set xpos so sprite will "spill over" LD C, 12 ; Set correction HorizClipDone: ; A = xpos ; E = ypos ; B = height ; IX = image address ; Now we can finally display the sprite. 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 ; Correct graph buffer address LD E, C ; if clipping the left side SBC HL, DE ; AND 7 JR Z, _Aligned LD C, A LD DE, 11 _RowLoop: PUSH BC LD B, C LD A, (clip_mask) ; Mask out the part of the sprite AND (IX) ; to be horizontally clipped 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 clip_mask: .DB 0 .end .end
426
« on: July 03, 2010, 08:50:23 am »
HA! looks really cool (NOTICE: this is a reaction on the Eye candy map you posted earlier I can't get my comment to appear below that...) but maybe you should make tiles that are rounded of so you get a smoother map. especially the "random" looking tile could use some smoothing on the edges! that makes the map not only less repetitive but just overally looking better (according to me...)!
427
« on: July 03, 2010, 07:55:08 am »
If send you a mail about my idea for a new faction. It's not even half way finshed but I think it is worth cehcking out and since I dunno what you cehck earlier, this or your mail i'll just sort of "remind" you here...
428
« on: July 02, 2010, 05:02:44 pm »
well here I am..infamous as I have become unfortunately due to the time difference instant messaging is not really a very realistic option. I must admit I have not worked on the campaign editor lately but I am back on it now and changing and tweaking some of the GUI. I know that that is not the most important part but unfortunately I still don't really understand how to make a appvar albeit I did understand the files "TileSet.txt", "TilePack.txt", "SingleMap.txt" and "Map pack.txt" which were posted here a while ago. I think I am going to reduce the color highlighting to two different colors, one for functions and one for the arguments. Also, what would be a prefferd token for adding comments? # or ; maybe, or just // ? So most of the time going into this is identifying for each line what the command is and thus were the arguments should be, then retrieve them and convert them appropiately into a appvar. maybe I will use a indirect method for this meaning that the 'parser' creates not just an appvar but a in between file aswell with all the arguments and functions neatly seperated and listed which is far easier to read out... well these are just ideas. I hope no one has problems with VB2008? since its only for windows....but then I am sure I might be able to put off a C-written parser. When you get the ideas and methodes sorted converting to a other language is not that hard... I hope to have informed you properly through this and I hope I'll get it done soon and 'well done'. Matthias1992 p.s UTI is not really my cup of tea I am more active on TI|BD. Its quite funny to see the same people as there here...at least, some of them...
|