Byte Knight Posted July 17, 2012 Share Posted July 17, 2012 This is one of those add-ons that doesn't seem so much like an add-on anymore. Especially with VisualbB support. I don't see any reason bB can't make Activision grade games now. Thank you very much for your work RevEng. Double thanks for updating it! Yes, thanks RevEng for making our games look so much better! 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 24, 2013 Author Share Posted August 24, 2013 I fixed a small score-corrupting glitch that would show up when using DPC+, thanks to iesposta's bug report. The kernel now stores a 0 in REFP0 and REFP1 before each frame, so it should fix the bitmap scrambling issue the loon reported. Find the new titlescreen kernel in the first post. If you have a project that used the last version, you can update it just replacing its titlescreen/asm directory with the one from the zip file. 2 Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 21, 2013 Share Posted October 21, 2013 Bug Report: I made a titlescreen using player0 and player1 in DPC+. I added " draw_player" in titlescreen_layout.asm I didn't find that in any documentation, however. When you press fire to go to the program there is colored garbage in the top left. When I copied the code to my program, there was still some garbage in the top left. I even set every player's "y" to 190 and it is still there. Is it leftover from the 48 pixel routine? Here is a .bin and the entire titlescreen folder, .bas file and .bin zipped up. TITLESCREENS_Title2013a.bas.bin Titlescreen DPC+ garbage.zip Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 22, 2013 Author Share Posted October 22, 2013 The titlescreen kernel temporarily borrows variables normally used by the bB kernel. The variables are returned to correct values when you call player definitions, etc., before calling the next drawscreen, but perhaps it's not quite fair to expect people to do that with the DPC+ kernel and all those players. In this case, you can skip full definitions by setting player9height to 0. I'll see about doing this for all used player0height variables when DPC+ is used, in an upcoming version. [edit] I see what you mean about the missing information in the docs. In the next version I'll fix that. Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 22, 2013 Share Posted October 22, 2013 Thanks for the quick fix. I always forget about player heights because I am not used to using them at all. Things seem to work without setting heights, but strange things can happen if you DON'T set them. I use player heights to change the sprite in an animation sort of way instead of a define sort of way -- but I think I should be doing both. Quote Link to comment Share on other sites More sharing options...
iesposta Posted December 7, 2013 Share Posted December 7, 2013 Byte Knight are having problems with the Titlescreen Kernel in bB DPC+ iesposta, on 07 Dec 2013 - 12:43 PM, said: (I did not know the game was resetting. I thought I was burning through my lives and it started over.) It looks like the bug has something to do with the "gosub titlescreendraw bank6". If I rem it and put a drawscreen in below it, then no bugs (except no titlescreen!). Also, when I wanted to put player0 and player1 "lives" on the titlescreen, two close triple copy players, if I put player0x=0 and player1x=15, player1y=15, player0y=15 they don't line up, but switch player0x=15 and player1x=0 they line up?! (The player is 15 high. player0y=0 makes it disappear.) On the Q*bert titlescreen I was able to use two players and have them move all the way across the screen together so I don't know why the above doesn't work when you flip things around. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 7, 2013 Author Share Posted December 7, 2013 Byte Knight sent me the program and I wasn't able to replicate it. He didn't send me the titlescreen package... are you guys using the latest? Any chance for a sample program that demonstrates the line-up issue? I didn't see this issue in the example binary, so it would help recreate it. Quote Link to comment Share on other sites More sharing options...
iesposta Posted December 8, 2013 Share Posted December 8, 2013 Byte Knight sent me the program and I wasn't able to replicate it. He didn't send me the titlescreen package... are you guys using the latest?Any chance for a sample program that demonstrates the line-up issue? I didn't see this issue in the example binary, so it would help recreate it.The Titlescreen folder is in the zip file in the PM thread I invited you to see, last page.Just search and flip player0x=15 player1x=0 and see if they don't line up. In the file: DK21gMKH.zip 70.24KB Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 8, 2013 Author Share Posted December 8, 2013 Ok, I'll take a look when I get a chance. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 9, 2013 Author Share Posted December 9, 2013 Apparently in the DPC+ memory map, player0x and player1x aren't adjacent. As a result, with DPC+ the player minikernel was doing positioning with player0x and temp7 . I fixed the player minikernel code so it doesn't rely on the variables being adjacent, and added the titlescreen_layout.asm information for each example in the docs. The first post has the updated version. 3 Quote Link to comment Share on other sites More sharing options...
clmiller Posted December 13, 2013 Share Posted December 13, 2013 Somehow I've managed to get two stray vertical bars, guessing associated with player0 & 1 (which aren't consistently placed from execution to execution) when using the Titlescreen kernel before switching over to the most basic playfield/drawscreen kernel. Has anyone else seen this? If I skip the title screen (gosub titledrawscreen bank2) these don't appear. I'm sure it's something I've done incorrectly. :/ Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 13, 2013 Share Posted December 13, 2013 Somehow I've managed to get two stray vertical bars, guessing associated with player0 & 1 (which aren't consistently placed from execution to execution) when using the Titlescreen kernel before switching over to the most basic playfield/drawscreen kernel. Has anyone else seen this? If I skip the title screen (gosub titledrawscreen bank2) these don't appear. I'm sure it's something I've done incorrectly. :/ Can you post the source for others to confirm/help? Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 13, 2013 Author Share Posted December 13, 2013 The titlescreen kernel borrows some memory locations (missile0x, missile0y, ...) expecting that you'll set them up before your game runs. Try setting missile0height=0, missile1height=0, and define the players before you do a drawscreen. (failing that, having source would help) 1 Quote Link to comment Share on other sites More sharing options...
clmiller Posted December 13, 2013 Share Posted December 13, 2013 Can you post the source for others to confirm/help? Definitely - here you go, thanks! playproject.zip Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 13, 2013 Share Posted December 13, 2013 The tall horizontal lines appear on the far sides for me. I somehow managed to get rid of one but the rightmost black line remains. Interestingly, the top 8+ pixels share player1s colors while the bottom half shares player0s color. Oh, and I'm pretty sure the playfield data is short a column. Quote Link to comment Share on other sites More sharing options...
clmiller Posted December 13, 2013 Share Posted December 13, 2013 The tall horizontal lines appear on the far sides for me. I somehow managed to get rid of one but the rightmost black line remains. Interestingly, the top 8+ pixels share player1s colors while the bottom half shares player0s color. Oh, and I'm pretty sure the playfield data is short a column. Good catch on the playfield. For me, sometimes those lines are way off to the right, sometimes split left/right, and sometimes somewhere in between. I suspect it has to do with wherever player0 and player1 end up at the point of pressing fire on the titlescreen? @RevEng, I might be missing other initialization values, but I do have player0/1 x/y and missile 0/1 x/y set at least. It's possible I'm missing something else though. Thanks all for the quick replies. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 13, 2013 Author Share Posted December 13, 2013 I changed this... if joy0fire && _joy0fire_debounce{3} then goto introinit ...to... if joy0fire && _joy0fire_debounce{3} then missile0height=0:missile1height=0:goto introinit ...and it seems to have cleared it up. 2 Quote Link to comment Share on other sites More sharing options...
clmiller Posted December 14, 2013 Share Posted December 14, 2013 I changed this... if joy0fire && _joy0fire_debounce{3} then goto introinit ...to... if joy0fire && _joy0fire_debounce{3} then missile0height=0:missile1height=0:goto introinit ...and it seems to have cleared it up. Brilliant! Thanks for tracking that down. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 14, 2013 Author Share Posted December 14, 2013 Not a problem. Quote Link to comment Share on other sites More sharing options...
iesposta Posted January 28, 2014 Share Posted January 28, 2014 With all the fixes and additions to DPC+ kernel, the Titlescreen 1.3 is giving me the following. Works perfect without the DPC+ box checked. But with the DPC+ box checked... Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 29, 2014 Author Share Posted January 29, 2014 I can't replicate it, but I think I know why its doing that. Can you replace this file in your titlescreen/asm directory and try again? [removed - replaced in full version, in first post] Quote Link to comment Share on other sites More sharing options...
iesposta Posted January 29, 2014 Share Posted January 29, 2014 I can't replicate it, but I think I know why its doing that. Can you replace this file in your titlescreen/asm directory and try again? 48x1_X_kernel.asm The color to the score is strange. Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 29, 2014 Author Share Posted January 29, 2014 Weird. Can you please zip up your titlescreen directory and attach it here or in PM? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted January 29, 2014 Share Posted January 29, 2014 I noticed that the title screen score retains whatever color cycling pattern the normal bB kernel was using. So, you could initially use the title screen and the score shading and color would be as expected. If you ever change the scores color during the game and re-use the title screen then it uses the changed colors. Not sure if this is related (or even a bug) Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 29, 2014 Author Share Posted January 29, 2014 Good one! That's what it looks like. If so, definitely not a bug. [edit - Worth saying that you need to make sure to set "scorecolor" if you use the score fade effect. With DPC+ normally you don't define scorecolor, you define the scorecolors: list, so it's easy to forget.] Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.