Secamline Posted October 26, 2016 Share Posted October 26, 2016 (edited) Hello there! Well, I think the title says it all. So this is just some clone of the game that plays in Google Chrome when there's no internet. It's pretty average and I absolutely need to fix some things like the score display, the obstacles' horizontal movement. But I'll let you be the judges of that. Edit : Here's a second version with some adjustments like a 4 digits score, smoother horizontal movement, difficulty choice and sprite animation. I deleted the title screen though because it doesn't really fit this kind of game. Atari VCS T-Rex (NTSC+PAL).zip Edited November 7, 2016 by Secamline 5 Quote Link to comment Share on other sites More sharing options...
Arenafoot Posted October 26, 2016 Share Posted October 26, 2016 awesome idea - got to 60 on the first try I love the old school scoring font (from the early Atari games). Quote Link to comment Share on other sites More sharing options...
Secamline Posted October 26, 2016 Author Share Posted October 26, 2016 Thanks, I didn't expect such a positive reply By the way, does anyone know how to make a title screen logo without using the playfield's gigantic pixels ? I assume we have to use the sprites' graphics but I just can't figure out how to do it. Thanks in advance. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 26, 2016 Share Posted October 26, 2016 Thanks, I didn't expect such a positive reply By the way, does anyone know how to make a title screen logo without using the playfield's gigantic pixels ? I assume we have to use the sprites' graphics but I just can't figure out how to do it. Thanks in advance. Use a 48 pixel routine. Read this topic. A more advanced option is to use a 96 pixel routine, which is basically spreading out the 48 pixels and putting them in different positions on alternating frames. Since you're just getting started go with the 48 pixel routine. Quote Link to comment Share on other sites More sharing options...
Secamline Posted October 26, 2016 Author Share Posted October 26, 2016 Thanks for your answer I tried implementing this routine but I can't get it to work, I guess I'm not experimented enough yet, so I'll stick with the playfield text for the moment. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 26, 2016 Share Posted October 26, 2016 You have to prep a number of things: Allocate 12 bytes of RAM for G48 G48 must be initialized to point to the graphic image to show. G48 and G48+1 are the first 8 pixels, G48+2 and G48+3 are the next 8 and so on. Y must be loaded with the number of scanlines to draw player0 must be positioned at 56 player1 must be positioned at 64 NUSIZ0 and NUSIZ1 must be initialized to 3 (three copies close) set bit 0 of VDELP0 and VDELP1 to 1* * can save a load instruction by using the 3 from the NUSIZx registers as only bit 0 matters. 1 Quote Link to comment Share on other sites More sharing options...
Secamline Posted October 26, 2016 Author Share Posted October 26, 2016 (edited) I've done everything, the four last sprites are displayed correctly, only the two first ones are messed up. Edited October 26, 2016 by Secamline Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 26, 2016 Share Posted October 26, 2016 Oops, I left off: set bit 0 of VDELP0 and VDELP1 to 1 The rest of the bits in those registers are not used, so you can save an instruction by storing 3 to them just like you do for NUSIZ0 and NUSIZ1. Quote Link to comment Share on other sites More sharing options...
Secamline Posted October 27, 2016 Author Share Posted October 27, 2016 Ok it works now, thanks again for your help, I updated the file. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 27, 2016 Share Posted October 27, 2016 Ok it works now, thanks again for your help, I updated the file. Something's not quite right, the title graphic is jumping all over the place. Quote Link to comment Share on other sites More sharing options...
Secamline Posted October 27, 2016 Author Share Posted October 27, 2016 That's weird, it works for me, does it have something to do with the emulator I use or..? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 27, 2016 Share Posted October 27, 2016 That's weird, it works for me, does it have something to do with the emulator I use or..? That's in Stella. Just dropped it on my Harmony and it looks OK on real hardware... Aha - it's related to the Drive Unused TIA Pins randomly on read/peek. When reading in values from TIA not all pins are connected. That can cause weird problems like this one in Medieval Mayhem (blog entry explains why the problem doesn't show up on all consoles). I leave that setting checked now to help find problems such as this. I do the same for the randomize options at the bottom of the I/O tab: Quote Link to comment Share on other sites More sharing options...
Secamline Posted October 27, 2016 Author Share Posted October 27, 2016 I see, and how do I fix this? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 27, 2016 Share Posted October 27, 2016 Use Stella's debugger to see what's going on. I turned off the "randomly" option on the TIA tab then reloaded the ROM. I then used the prompt and entered trap RESP0 to see when the reposition occurs as we know the problem's related to the positioning of the players. I then clicked on exit (or hit the ` key) and noticed it was on cycle 40 of the current scanline. The green box in the listing is the current instruction, you'll notice it's the line just after the STA RESP0. I hit ` a few more times and it was consistently on cycle 40. I then turned the "randomly" option back on and hit ` a few more times and noticed the cycle was different every time: 12, 8, 36, 44, etc. A little bit above that in the code I noticed a loop: LDX CXPPMM LF0DA: DEX BNE LF0DA CXPPMM is one of those TIA registers where not all bits are connected. Specifically, only bits 6 & 7 are used: When the "randomly" is off, that value comes back $87 - the lower nybble is 7 because the 6 bit address CXPPMM is 7! With "randomly" on that value comes back as: $9F, $BF, $87, etc. So that loop will take a different amount of time on some Atari systems. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 27, 2016 Share Posted October 27, 2016 A very common mistake is to leave off # when you're typing in an immediate mode instruction. If you wanted to load register X with 7 the instruction is LDX #7. If you left off the # then LDX 7 on the Atari is the same as LDX CXPPMM because that's the name of the register accessed at address 7. Quote Link to comment Share on other sites More sharing options...
Secamline Posted October 27, 2016 Author Share Posted October 27, 2016 (edited) What I don't understand is that I never use the CXPPMM register in a loop in my code. EDIT: Oh! Ok, now I get it, what a stupid mistake really ^^ Edited October 27, 2016 by Secamline Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 27, 2016 Share Posted October 27, 2016 It's a common mistake. Turn on the "randomly" and when (not if) you do it again the weird results will help you find and fix the typo. Quote Link to comment Share on other sites More sharing options...
Secamline Posted October 27, 2016 Author Share Posted October 27, 2016 Ok, thanks for your advice. Quote Link to comment Share on other sites More sharing options...
Secamline Posted November 3, 2016 Author Share Posted November 3, 2016 I fixed most of the problems the game had in the last update, but sometimes the number of scanlines jumps to 263 for a split second, is it important to have a 100% stable scanlines number or can I ignore that ? (considering this instability doesn't cause jittering) Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted November 3, 2016 Share Posted November 3, 2016 Yes, that'll cause the display to jitter. Another issue is an odd number of scan lines on PAL 2600s will cause the display to lose color, and thus be drawn in only black & white. While I don't know for sure, being in NTSC land and all, I suspect the frame of color loss would be even more noticeable than the jitter. Quote Link to comment Share on other sites More sharing options...
Secamline Posted November 3, 2016 Author Share Posted November 3, 2016 You mean it will jitter when playing on a real hardware? In Stella, with the jitter option enabled, it doesn't seem to affect the display when there are 263 scanlines. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted November 3, 2016 Share Posted November 3, 2016 Yes, on real hardware. I just tested it using jitter.bin to confirm it by changing the number to 127 (or 129) then repeatedly hitting fire - the screen jitters up/down. It should have in Stella too, it did so when I first implemented jitter support. I just tested that build and the second one to confirm it; however, as of the third build it only jitters if the difference is 2 scanlines. As such I must have changed something on accident when I added recovery time(that's when it takes multiple frames to recover from a large change in scanline count). I've added looking into that to my To Do list. 1 Quote Link to comment Share on other sites More sharing options...
Secamline Posted November 4, 2016 Author Share Posted November 4, 2016 I managed to make a stable scanline number during gameplay, but when the game resets (each time you get hit), it becomes very unstable for 2-3 frames. Quote Link to comment Share on other sites More sharing options...
gauauu Posted November 4, 2016 Share Posted November 4, 2016 Keeping the scanlines stable during all the transitions was one of the harder parts of the process for me. I ended up making a subroutine that would wait for my frame timer to finish, draw an entire blank frame, and then properly reset all the timers. Then during transitions, if things were taking too long, I could change the code so that it called this subroutine halfway through. There's probably a better way (I'm still a bit of a newbie around here) but that ended up being an easy solution for my transitions. Quote Link to comment Share on other sites More sharing options...
Secamline Posted November 5, 2016 Author Share Posted November 5, 2016 Alright I updated the file once again. I made something similar to your solution and this time it looks like the display is entirely stable. 1 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.