Cybearg Posted March 17, 2013 Share Posted March 17, 2013 So I'm trying out DPC+ and I have an issue: my player 0's missiles go black once they extend beyond the range of the sprite. I've tried using COLUM0 = $2C, but it doesn't seem to make any difference. How can I keep the player 0 missile the same color as player 0? Quote Link to comment Share on other sites More sharing options...
Byte Knight Posted March 17, 2013 Share Posted March 17, 2013 So I'm trying out DPC+ and I have an issue: my player 0's missiles go black once they extend beyond the range of the sprite. I've tried using COLUM0 = $2C, but it doesn't seem to make any difference. How can I keep the player 0 missile the same color as player 0? Missile0 doesn't work very well with DPC+ for some reason - you'd be better off using the ball sprite... Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted March 17, 2013 Share Posted March 17, 2013 Byte Knight is correct. I noted that in post #10 and iesposta gave a sample program about that behavior in post #11 in my "getting started with DPC+" thread (http://www.atariage.com/forums/topic/209496-getting-started-with-the-dpc-kernel/). Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 17, 2013 Author Share Posted March 17, 2013 But can the ball be somehow set to a different color? Won't it always take on the color of the playfield it's in line with? If so, I can't use the ball, then, because most of the screen is playfield and that would make the ball invisible. Quote Link to comment Share on other sites More sharing options...
Byte Knight Posted March 17, 2013 Share Posted March 17, 2013 You could also use one of your many sprites available - make it into a fancy arrow or something! Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 17, 2013 Share Posted March 17, 2013 The color problem is a bug with 1.1d. The unoffical fix is attached - unzip (with directory structure) into your project directory. I'll post the bug and the source fix in one of batari's threads shortly. bB_DPCplus_1.1_COLUM0_fix.zip dpcgame2.bin Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted March 17, 2013 Share Posted March 17, 2013 The color problem is a bug. The unoffical fix is attached - unzip (with directory structure) into your project directory. I'll post the bug and the source fix in one of batari's threads shortly. bB_DPCplus_1.1_COLUM0_fix.zip dpcgame2.bin Thanks, Mike. Attached is my latest bB DPC folder that has your fix and also includes the most recent files from batari from this thread:http://www.atariage....-version-of-bb/. I'll include this in the first post of my "getting started" thread as well.BB_dpc_03.17.13.zip 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 17, 2013 Share Posted March 17, 2013 Arrrr. Now with the changes I'm getting: 2600 Basic compilation completed. DASM V2.20.07, Macro Assembler ©1988-2003 free ram: 9 DPC free RAM= bytes of ROM space left in bank 1 bytes of ROM space left in bank 2 bytes of ROM space left in bank 3 bytes of ROM space left in bank 4 bytes of ROM space left in bank 5 bytes of ROM space left in bank 6 bytes of ROM space left in graphics bank free ram: 9 DPC free RAM= 603 --> getbackearly 1aaa Compilation completed at 3/17/2013 5:56:17 PM Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 17, 2013 Share Posted March 17, 2013 Did you have 1.1d working before? Anybody else have this problem? Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted March 17, 2013 Share Posted March 17, 2013 Did you have 1.1d working before? Anybody else have this problem? This isn't helpful to iesposta I know, but I applied your fix and was able to recompile my demo "dpcgame2.txt" successfully, and it resolved the missile0 color problem. Actually it resolved another problem for me, I now see the bytes free in each bank when I compile - although maybe that was just because of starting over with a fresh install in a new folder. Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 17, 2013 Share Posted March 17, 2013 I also recompiled your dpcgame2 and saw the left side stay red, but it broke my bytes free. I spent the afternoon in OSX making a compile environment for the ARM "custom2.bin" so I could compile it myself and try to fix COLUM0, then just as I had a successful build, I checked here and saw RevEng posted a fix. I copied the expanded zip files from OSX to Win 7. I'll try downloading them and unzipping them all in Windows. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 18, 2013 Author Share Posted March 18, 2013 Thanks, Mike. Attached is my latest bB DPC folder that has your fix and also includes the most recent files from batari from this thread:http://www.atariage....-version-of-bb/. I'll include this in the first post of my "getting started" thread as well. I tried this new version. Works great for fixing the missile bug, but now there are a couple other things: 1. I'm having the opposite issue from Atarius. I WAS able to see my remaining ROM sizes, but now I can't with this change. 2. The entire player sprite takes on the color of COLUM0, so it overwrites the player0color data set. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 18, 2013 Share Posted March 18, 2013 I don't know what to say guys about the compile output or lack of compile. The change I made was to literally comment out 2 asm subtract commands, and a change to the arm binary file. Neither of these should cause compile problems. I can't recreate your #2 issue Cybearg. (see my compiled version of Atarium Maximus' attached dpcgame2.bin above) Are you using player0color:? If so, can you post the files? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 18, 2013 Author Share Posted March 18, 2013 Here you go. Player0 should be yellow and missile0 should be white. If you climb to the top of the tallest building (just hold up), you can see that some color creeps into player0's sprite. It seems that the player's colors are stuck to the top of the screen. omega.bas.bin omega.bas Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 18, 2013 Share Posted March 18, 2013 Not seeing it... omega.reveng.bin Did you unzip it my update into your project directory, or did you take Atarius Maximus' update? If you unzipped my update, do you see a "custom" folder, with a "bin" folder inside it? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 18, 2013 Author Share Posted March 18, 2013 (edited) Did you try the .bin I uploaded or just the .bas? Anyway, I used Atarius's drop-in files. It does come with a custom directory with a bin file, though I get nothing when I play it in Stella. Edited March 18, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 18, 2013 Share Posted March 18, 2013 I tried the bin and saw the effect. I compiled your bas, and it went away. Your results are what I'd expect to see if someone used the kernel patch but not the updated custom2.bin... so for some reason it's not getting used, but Atarius Maximus didn't see this same problem, so I'm thinking it might be PATH setup issue with vbb? Try compiling from the command-line and see what you get. Also, make sure you see the includes/custom/bin/custom2.bin directory structure your bB directory. Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted March 18, 2013 Share Posted March 18, 2013 I tried the bin and saw the effect. I compiled your bas, and it went away. Your results are what I'd expect to see if someone used the kernel patch but not the updated custom2.bin... so for some reason it's not getting used, but Atarius Maximus didn't see this same problem, so I'm thinking it might be PATH setup issue with vbb? Try compiling from the command-line and see what you get. Also, make sure you see the includes/custom/bin/custom2.bin directory structure your bB directory. The zip file that I attached does include the \custom\bin subdirectory with the custom2.bin in it. Edit: So I feel like I'm not being all that helpful here, but I wanted to confirm that I see the same thing as RevEng. I see the issue in Cybearg's bin, but I when I compile it myself the problem goes away. Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 18, 2013 Share Posted March 18, 2013 (edited) More odd things. I can make the changes in my DPC..._.asm file and copy the new custom2.bin over and it works. Drag copy the unzipped DPC..._.asm file over and replace and it does not work. Even more odd. The temp folder that had the dpcgame2.bas now compile errors with something wrong in bank 1 and missing font declaration But wait, it gets better. The exact same text for dpcgame2.bas in my Satan's Hollow folder compiles fine! They are exactly the same. Copy one to the other. Won't compile in temp project director, ok in Satan's Hollow directory. Also the bouncy background screen that I figured out, that compiled in the temp directory won't compile anymore. says: --- Unresolved Symbol List font 0000 ???? (R ) Fatal assembly error: Source is not resolvable. Errors were encountered during assembly. Copy it to another Project directory it compiles fine! God, Windows sucks! Both temp folder and Satans Hollow folder are in the Projects folder. There has to be some invisible configuration saved between project folders because why would the same code act different in different project folders? Edited March 18, 2013 by iesposta Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 18, 2013 Author Share Posted March 18, 2013 I tried reverting to Atarius' earlier bb_DPC set-up that I've been using, then applied your patch alone, Rev. I get the same issue. And yes, the custom2.bin is within the \custom\bin\ directory, though I don't know what it does. Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 18, 2013 Share Posted March 18, 2013 (edited) Atarius you have 2 custom2.bin files in your zip upload. One in includes\custom\bin folder (old custom2bin) and one in custom\bin folder (new custom2.bin) EDIT: Cybearg: The new custom2.bin file has to go in the includes\custom\bin\custom2.bin Edited March 18, 2013 by iesposta Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted March 18, 2013 Share Posted March 18, 2013 Ok. I'll delete the zip attachment and post a corrected one. Edit: My original attachment has been updated. I had the \custom folder in the root rather than in the \includes folder. I tested Cybearg's omega.bas again and it looks fine. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 18, 2013 Author Share Posted March 18, 2013 That fixed it! Still am not seeing my ROM sizes reported though, sadly. Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 18, 2013 Share Posted March 18, 2013 That fixed it! Still am not seeing my ROM sizes reported though, sadly. Can you just edit the original DPCplus_...asm file? You just need to add two semicolons ; That fixed it for me! Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 18, 2013 Share Posted March 18, 2013 Use the original DPCplus_kernel.asm in the /includes/ folder Find and change this by just adding the two semicolons with a text editor or wordpad: sec lda #<(P0COLOR-1) ;sbc #0 sta DF0LOW sta temp2 lda #>(P0COLOR-1) ;sbc #0 sta DF0HI 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.