Asmusr Posted October 25 Share Posted October 25 9 hours ago, Cheung said: For XB, I think the hardest part about this game would be the interior wall detection, since the walls don't appear to be characters and are drawn lines and thus would not be able to easily use character type from a GCHAR to determine if the space can be occupied by the player, missiles, enemy, etc. Why do you think the walls have to be drawn as lines? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 25 Share Posted October 25 This is from the arcade version with an 8x8 grid overlay. 3 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted October 25 Share Posted October 25 2 Quote Link to comment Share on other sites More sharing options...
Cheung Posted October 25 Share Posted October 25 (edited) 4 hours ago, Asmusr said: Why do you think the walls have to be drawn as lines? They don't *have* to be drawn as lines, but it's easier if they are WRT accurate collision detection with the walls, on a pixel level, unless you can PEEK pixel colors in character graphics mode, which I don't think you can. Edited October 25 by Cheung Quote Link to comment Share on other sites More sharing options...
Retrospect Posted October 25 Author Share Posted October 25 36 minutes ago, Cheung said: unless you can PEEK pixel colors in character graphics mode I bet even if we could do that we'd still be limited to the character space it occupies rather than which pixel the colour is at. 1 Quote Link to comment Share on other sites More sharing options...
Cheung Posted October 25 Share Posted October 25 This image Rasmus provided doesn't make sense to me as far as the screen adhering to the character boundaries - the numeric score seems to be a character and a half tall, the player sprites and enemies look to be 2 and a half character tall and wide. Quote Link to comment Share on other sites More sharing options...
JasonACT Posted October 25 Share Posted October 25 I'm going to ask 1 question, then disappear from this interesting thread... How does Parsec know when to crash my ship when I hit the oddly shaped ground? (I've always wanted to ask/know that.) Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 25 Share Posted October 25 4 hours ago, Cheung said: This image Rasmus provided doesn't make sense to me as far as the screen adhering to the character boundaries - the numeric score seems to be a character and a half tall, the player sprites and enemies look to be 2 and a half character tall and wide. I was in a bit of a hurry when I posted it so I didn't have time to write very much, but the purpose was just to illustrate that it's possible to draw the screen with a very limited number of characters. On the arcade hardware they must have sprites bigger than 16x16, and maybe they do indeed use a bitmap screen, or they use sprites for the red text, or they have multicolor characters. However, on the TI, I think normal graphics mode would work fine. Since your wall characters don't fill the entire 8x8 pixels, you could have a table of top/bottom/left/right margins for each character that you use to decide how far a sprite can move into the character before it's blocked. 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 25 Share Posted October 25 (edited) This is a similar screenshot from the Colecovision. Quite impressive that they have maintained the original sprite size. (actually it looks like the sprites are 16x16). Edited October 25 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
Cheung Posted October 25 Share Posted October 25 (edited) 5 hours ago, JasonACT said: I'm going to ask 1 question, then disappear from this interesting thread... How does Parsec know when to crash my ship when I hit the oddly shaped ground? (I've always wanted to ask/know that.) I don't know how the TI checked for this but if I were programming the game in another language for a newer system, I would bitwise XOR the ship with the ground pixels at the upcoming location and check to see if the result was different from the ship pixel data. Edited October 25 by Cheung 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 25 Share Posted October 25 1 hour ago, Cheung said: I don't know how the TI checked for this but if I were programming the game in another language for a newer system, I would bitwise XOR the ship with the ground pixels at the upcoming location and check to see if the result was different from the ship pixel data. I don't know about Parsec, but a simple check on position might work better than expected. For instance, TI Scramble, Jet Set Willy, and Bouncy's Obstacle Run use the simple method. With smooth scrolling games I have added the pixel scroll offset into the equation to make the collision detection more accurate. Let me check what Parsec is doing... 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 25 Share Posted October 25 (edited) Parsec is checking 10 positions on the player sprite against the background data. That must be taking a long time, but explains why Parsec's collision detection is so accurate. ******************************************** * THIS SUBROUTINE CHECKS FOR COINCIDENCE * * BETWEEN THE SHIP SPRITE AND SCENERY * ******************************************** COINCK MOV R11,R10 SAVE RETURN ADDR LWPI FASTWS-32 CLR R5 SET TABLE POINTER CB @YXLOC1+0,@H71 UPPER-LEFT SPRITE(16 PIXELS OFFS JL RETJOY NO, SO DON'T CHECK STARS OR YOU MORCOI MOVB @YXLOC1+1,R0 GET XPT OF UPPER LEFT CORNER OF MOVB @YXLOC1+0,R1 GET YPT OF UPPER LEFT CORNER OF AB @COINX(R5),R0 ADD IN COIN OFFSET TO YPT AB @COINY(R5),R1 ADD IN COIN OFFSET TO XPT SRL R0,8 CLEAR AND PLACE IN LOW BYTE SRL R1,8 CLEAR AND PLACE IN LOW BYTE BL @PTADR R1=BYTE AT VDP ADDR,R3=POINTER T ANDI R1,>FF00 CLEAR TO HIGH BYTE ONLY SLA R3,1 WORD BOUNDARY FOR BIT MASK TABLE COC @MSKSCN(R3),R1 COMPARE BIT IN CHAR W/ BIT IN SP JEQ BRBOOM SAME, SO COIN DETECTED, GO BLOW INC R5 NOT THE SAME BIT SET, SO TRY NEX CI R5,10 DONE CHECKING ALL BIT SPOTS IN S JNE MORCOI NO, SO KEEP CHECKING MORE BIT P RETJOY LWPI FASTWS B *R10 YES, SO RETURN TO SCAN - NO CRA BRBOOM LWPI FASTWS LI R4,>940A PRE-LOAD CHAR AND COLOR FOR EXPL LI R10,MSGSCN PRE-LOAD CRASH W/ GROUND MSG CB @REFFLG,@H02 ANY REFUELING GOING ON IN THE TU JL GROCOL NO -- --- -- BL @SPSUB EXECUTE SPEECH PHRASE "PILOT ERR DATA 23 SHIP LOST" LI R10,MSGWAT YES, SO GET CRASH W/ TUNNEL MSG GROCOL B @GOBOOM EXPLODE !!! ******************************************************** * PTCTL--POINT CONTROL SETS OR RESETS ONE PIXEL * * INPUT PARAMETERS * * R0=XPT=PIXEL DISTANCE FROM LEFT OF SCREEN * * R1=YPT=PIXEL DISTANCE FROM BOTTOM OF SCREEN * * R2=SET/RESET DATA 0=RESET NONZERO=SET * * * ******************************************************** PTADR EQU $ MOV R0,R3 MOV X POINT TO R3 MOV R1,R4 MOV Y POINT TO R4 ANDI R3,>0007 SAVE BIT POSITION IN PATT BYTE PAGE 0057 SZC R3,R0 STRIP OF 3 LSB'S FROM X-POINT SLA R0,3 MPY ADUSTED XPT BY 8 SRA R4,6 SAVE 2 MSBITS OF YPOINT ANDI R1,>003F KEEP 6 LSBITS OF YPT:DONT SHFT SOCB @OFSTBL(R4),R0 MASK IN TWO BITS A R1,R0 ADDRESS OF BYTE NOW IN RO GETBYT LIMI 0 MOVB @FASTWS-31,@VDPWA MOVB R0,@VDPWA MOV R0,R0 MOVB @VDPRD,R1 LIMI 2 B *R11 RETURN TO CALLER NOW **************** * TABLE AREA * **************** MSKSCN DATA >8000,>4000,>2000,>1000 BIT MASK FOR COIN DATA >0800,>0400,>0200,>0100 ON SCEEN DATA COINY BYTE >06,>07,>0C,>0C,>0C,>0A,>09,>03,>03,>06 Y OFFSE COINX BYTE >00,>00,>00,>04,>07,>0C,>0F,>03,>07,>0C X OFFSE Edited October 25 by Asmusr 13 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.