-
Content Count
1,722 -
Joined
-
Last visited
Posts posted by TwentySixHundred
-
-
First release ROM of this WIP - feel free to have a play around on the first level
Far from perfect and lots of work to go however it is playable
Latest Build: Captain Comic.bas.a78
-
14
-
-
Looks Great! Thanks for the update cant wait to try it out 👍
-
2
-
-
Looking really good so far, nice job 👍
-
1
-
-
Best advice i have if you have no idea where to start is to make it simple. Get some sprites on the screen and start moving them around with the joystick ect. Learn about playfields and screen transitions along with TIA registers so you can change colours and create some sounds. It's best to experiment first with these simple fundamental parts then you can progress into something more like a game. The learning curve is steep to begin with but gets easier over time
-
3
-
1
-
-
Case closed, turns out some bad math on my part that Mike had found and the double width value that Karl pointed out. Cheers Mike, Karl and Mord for giving a hand, much appreciated 👍
-
4
-
-
36 minutes ago, RevEng said:No worries. I'm glad to leave it in your hands, and I'm glad to continue working things out too. Whatever it takes.
Last question, before I leave you to it. Are you sure mytemp1 and mytemp2 are dimmed to otherwise unused variables?
Thanks yeah it's the last major piece to the engine other then refinement. Everything else is fairly solid besides platform detection (crucial to making a platformer fun). So im determined to make it work one way or another 😀Once the engine is nailed then i can take level design more seriously.
Yes indeed the mytemps are dimmed to their own independent variable locations. The ramcharmap sample code i broke down worked fine other then a sprite display bug, the platform part was all good though, so i thought it was enough.
-
1
-
-
24 minutes ago, RevEng said:Aside from looking at that, I think you need to temporarily disable the falling code, and just add some temp code allow your player to be moved all around the screen by joystick. See if the values change where they should, and what they change to.
I think you're right, i should probably create a test program rather then testing within the engine i have. There could be something else causing an issue within the engine im using and im completely overlooking it. I will have a go tomorrow with a program that has nothing other then a couple of sprites and some tiles to simplify things a little.
Usually i create test programs for anything new i learn, however this time i think i jumped the gun 👍
-
1
-
-
10 minutes ago, RevEng said:The 7800 has locations of ROM that graphics need to go into, so they display properly. Each time you do an "incgraphic mygraphic.png" it will import graphics into the current graphics block, until it's full, and then it moves on to the next. If you check the compile messages, you'll see stuff like...
*** (): INFO, GFX Block #1 starts @ $A000 mysprite1 mysprite2 playfield_tiles [...]In the above example, the first "playfield_tiles" character won't be character index "0", because there are other graphics that proceed it in it's graphics block. To force it to be at position 0, you'd reorder things so playfield_tiles comes first. (and if there are other incgraphic statements prior, you might need a "newblock" before the incgraphic for the tiles.)
Aside from looking at that, I think you need to temporarily disable the falling code, and just add some temp code allow your player to be moved all around the screen by joystick. See if the values change where they should, and what they change to.
Thanks, so now the graphics locations makes more sense. Yeah i am seeing the tallsprites in block 1 and obviously the tilesets are in bank 32 because that's an persistent bank? Im guessing that could be causing issues?
*** (): INFO, bank #1, GFX Block #0 starts @ $A000 playerstand playerstand_tallsprite_00 playerstandr playerstandr_tallsprite_00 playerwalk1 playerwalk1_tallsprite_00 playerwalk2 playerwalk2_tallsprite_00 playerwalk3 playerwalk3_tallsprite_00 playerwalk1r playerwalk1r_tallsprite_00 playerwalk2r playerwalk2r_tallsprite_00 playerwalk3r playerwalk3r_tallsprite_00 *** (): INFO, bank #1, GFX block #0 has 3072 bytes left (192 x 16 bytes) *** (): INFO, bank #1, DMA hole #0 starts @ $B000 no code defined for DMA hole *** (749): WARNING, image contains more unique colors than 160A allows *** (): INFO, bank #32, GFX Block #0 starts @ $C000 tileset_blanks tileset_grassy tileset_lake tileset_fort scoredigits_8_wide alphabet_8_wide *** (): INFO, bank #32, GFX block #0 has 0 bytes left (0 x 16 bytes)2 minutes ago, RevEng said:The value returned isn't BCD format, so if plotvalue displays "64", it's actually "$64".
To be honest i think im plotting the value wrong, i tried to display one of the temps and it's just a static value. Im not having a good run at the moment 😄
-
52 minutes ago, Karl G said:So, it didn't work when you changed it back to dividing by 8, and checking for playerchar=10, either? If so, I'm out of ideas at the moment. Maybe someone smarter and more experienced with 7800basic will figure it out, though.
Still no dice, and now even after throwing random numbers nothing is changing. I have no idea why this simple command is not making sense to me yet 😄
52 minutes ago, RevEng said:Just to check it off the list, did you copy the level rom data to your screendata memory with memcpy? Heads up that if you have other graphics in the block before your characters, the values will be offset.
Also, try displaying what peekchar is returning on the screen, with plotvalue. That helps with debugging.
Yeah Mike i have been using memcpy to store the alphadata into RAM. Not 100% sure what you mean by graphics in the block before characters although i can stab any values in there and still get the same freefalling result.
After plotting the value im getting 64 but this never changes whilst the player is freefalling. I would assume as the player pos updates so would peekchar in return making the value change depending on the tile the player is over.
Im sure it's something really simple im just overlooking or have left out 😄
EDIT: So interestingly i have changed the condition statement to
if playerchar=64 then P0C3=$30 : goto DONEFALLINGJust to see what would happen and turns out the playerchar value is not 64.
-
Yeah i divided by 4 to test if there was any effect as 8 wasn't working. Also yeah i flipped the temps around for x and y without changing the comments lol. To be honest it's usually how i reverse engineer code samples i don't fully understand. By temporarily switching things around and watching for whatever crazy results occur, i can usually work out what effects what lines of code. #visual_learner 😄
-
Thanks Karl and yeah that makes sense since you pointed it out although im still getting the same result though. No matter the value im checking none seem to work besides 0, however strange things happen without rhyme or reason. Also just been throwing different random values at everything but that's not causing much of a difference either. Cheers anyway 👍
-
Ok so after having a chance to play around tonight and try to work out exactly whats going on with peekchar, still no dice. After having a read through the Mikes blog and breaking down the ramcharmap sample i have ended up with this. Makes sense to me, however im obviously missing something here as the player just freefalls. Also i am using tallsprites, doublewide, preloaded RAM tiles and 160A mode
mytemp1=(playerx+4)/8 : rem 8 is our zoneheight mytemp2=playery/4 : rem 4 is 160A character width, but x2 for doublewide mytemp2=mytemp2+1 : rem the block under our feet playerchar=peekchar(screendata,mytemp1,mytemp2,20,12) if playerchar=5 then P0C3=$30 : goto DONEFALLING playery=playery+1.0 ; player grav DONEFALLINGIm sure there is something im overlooking
-
Sorry to bump this topic but i have been racking my brain for some time with peekchar. Im wanting to read an individual alphadata value stored in RAM for platforms/gravity ect. The method i have been using is too dodgy and long winded and id rather just call for what tiles the player is standing on. After breaking down the ramcharmap sample it's still going over my head as for understanding how to read the correct tiles.
Might have a rest for tonight and reload tomorrow, just waiting for this to click and make sense. Anyway i could be back with some layman questions lol
-
Plays, looks and sounds really solid, a whole lot of fun! Very nice work guys the scrolling is really smooth 👍
-
On 8/18/2020 at 7:41 AM, Jinks said:Test Drive! Wow!!
Finally a 7800 racing homebrew!!
The 7800 homebrew scene is on fire!!
Thanks, yeah it will be loosely based of the original TD series. Same as Captain Comic both wont be one for one ports but rather inspired by. Im a little hesitant to release a playable ROM at the moment. They're far from done and basically just game engines so rather then have people play for 2 minutes and become bored id rather wait till there is something substantial. Thanks for the interest 👍
-
7
-
-
I popped in for a moment during the live stream although was busy so couldn't continue to watch. Had a chance last night to watch the full interview on youtube.
Really cool, i enjoyed watching the interview with Darrel and listening to what he has to say in person. Was looking forward to this and Darrel truly is an asset to the Atari Age community.
Very enjoyable! Thanks for the hard work James in regards to making this happen 👍
-
5
-
-
Well done guys can't wait to give this one a whirl later tonight
-
2
-
-
Well done, sound will definitely bring this to life even if simple bleeps and bloops. I must say i felt a little ripped off that my last 20 "cents" was taken and gameover. Maybe that one last spin?
-
1
-
-
Well, after breaking down the ramcharmap sample and help from you guys explaining how storing data into RAM works, we're cooking with gas
I had to rewrite the example into what would work with my game engine and bankswitching scheme but it works flawless!
Only issue and not really an issue is i need to re-initialize the includes for tallsprites after bankswitching. However this routine is only ever called once during screen transitions so nothing too major. Im yet to see if i need to re-initialize the color pallets (thinking i don't), although at this moment im re-initializng them anyway.
This is exactly what i was after and had pictured in my head as an ideal method for retrieving charmap data in non persistent banks. Thanking you both for taking the time to explain how it works, much appreciated 👍
Now i have 29 remaining banks to fill with charmaps 😄
Edit: Maybe if i move the game engine back to bank1 rather then 2 (by DPC+ habit) i may not have to re-initialize those tallsprites after bankswitching 🤔 Either way i got plenty of ROM to spare.
-
1
-
-
Once again thanks guys, this is exactly what i was looking for
Just need to work out exactly what im doing with memcpy and memset. I will have a good look at the ramcharmap sample tomorrow with a fresh set of eyes. I remember skim reading those functions in the guide but it kinda went over my head as a novice to 7800basic.
Yeah come to speak of it i did duplicate the engine into separate banks with Bass Fishing for simplicity and more cycles as i had an overcycle issue at one point. Just made things easier to maintain and optimize however id probably rewrite the whole engine if i were to touch it again lol.
@RevEng That is correct, i got really comfortable with DPC+ and all its ARM goodies.
Personally i would like to use the RAM method and have a single engine {mainloop}. Thanks for the help ill get some sleep and look at storing data into RAM tomorrow. Never hurts to learn something new 👍
-
1
-
-
Cheers guys yeah both explanations are indeed helpful for getting a full understanding as to what is going on. Obviously very different to how bB handles stored data (with DPC+ anyway). So im still trying to wrap my head around the different modes and how to access stored data correctly.
Yes i had also forgot to mention i worked out that storing the data in a persistent bank for example the last bank did work. Although with a large ROM i was hoping to get a little greedy, and utilize the other remaining non persistent banks as mass storage for character data. So from what i understand to achieve this i would need to use the store-in-RAM method. The only other method i could think of (not really ideal) would be to have the engine in each bank and fill the rest of the bank with character data ect.
Im thinking converting and storing the alpha data into RAM then extracting when in the main engine bank wouldn't be all that straight forward either. I mean there is no shortage of RAM so that's a good thing, however im still thinking about how to tackle that method and if it would be a viable option.
Also thanks for explaining how the savescreen function works, makes alot more sense now 👍
-
Hi guys, i have been trying to access alphadata tables for screen transitions and obviously no issue when those tables are stored in the same bank. When storing them in another bank - reading - returning to engine bank, the data is lost and the tiles are jumbled up. I have suspicion savescreen only remembers the data till the bank is switched? Which then leads me to think in order to retrieve that data it would need to be stored in RAM? Is my suspicion correct or is there a trick to retrieving alpha data from another bank then plotting the tilemap in the engine bank?
I was thinking you could jump to a label in another bank then clearscreen - plotmap - savescreen then returning to engine bank however no luck there. Also tried some other variations of this method without any success so far. Im sure there has to be a simple way to retrieve that data
-
Yeah installed straight to desktop with no whitespace in the path, still no go, was worth a try though. It's all good anyway i probably wont worry about pokey and using the XM module. See how things go in the future when a7800 is compatible with pkey and bankswitching
-
1
-
-
1 hour ago, RevEng said:Sadly, not a whole lot of helpful info there.
Just one shot in the dark - can you try setting up a7800 in a location without spaces in the path? I don't think it should make a difference, but it's the one thing that's sticking out to me.
Yeah noticed that and wondered and thought the same, makes sense when compiling but never had an issue with whitespace using emulators. I will have a look tonight and see what happens 👍

Captain Comic
in Atari 7800 Programming
Posted · Edited by TwentySixHundred
Thanks, yeah the palettes seem to be one the strangest parts to the 7800. Some animated sprites will start flickering with incorrect colours each frame and need to be corrected on the fly by switching the pallet values. It's definitely one part i really need to look into.