Jump to content
IGNORED

Can someone test this on a CC2


kenfused

Recommended Posts

This looks very nice so far.

 

It seems on this demo that the sprites slow down when there are a lot on the screen, and they move quite nice when there are only a couple, I hope that gets worked out when they actually start moving on the platforms.

I also know this is very early in the stages of development, so it is looking stellar so far 8)

Link to comment
Share on other sites

I have to ask though, how has your experience been with converting from 5200 to 7800? Has it been difficult for you or is it pretty much just following standard procedure and working out the bugs that pop up along the way?

Link to comment
Share on other sites

Hmm..running the sprite demo (Which is really what this is..a display and sprite demo...so far.), The sprites move very well on my system. If your doing this in emulation, then it could be your system is slowing down with all the stuff on the screen. Still, I think I have managed to count about 7 or 8 sprites on the screen at once. That is still more than what I think every appears on the 5200 version. So more likely than not it just needs to be optimized somewhat. And the actual game wouldn't really have all that many sprites moving about anyway. But, then again, they would have some A.I. applied to them in the game which might slow things down.

 

Still look at Robotron, Galaga, Food Fight. They all use tons of sprites on the screen at once and never does the 7800 slowdown. Galaga is a glitch..not a problem with the hardware. And even then it just suddenly goes insanely fast after wave 10. It doesn't slow down...

Link to comment
Share on other sites

If your doing this in emulation, then it could be your system is slowing down with all the stuff on the screen. Still, I think I have managed to count about 7 or 8 sprites on the screen at once.

 

I am running it on the CC2, and it seems the sprites move kind of choppy when there are 6 or 7, but when it goes down to 2 they move more smooth/quicker.

Link to comment
Share on other sites

Just cos I was curious to see how it would work on a PAL 7800...

 

http://62.168.142.47/~mayhem/images/beefdrop.jpg

 

Garbage at the bottom (due to PAL's extra lines) but the display is pretty much there, just need to adjust colours. I'd love a PAL version hint hint ;)

 

So if you're up for doing it for both systems, I'll be the volunteer PAL tester :)

Link to comment
Share on other sites

I reorded a couple of things.  Doubt if it will have any effect but it is worth a shot.

Wow, this looks promising :)

Was the opposite DLI the problem?

I was actually enabling screen DMA before setting the display list list pointers so who knows what effects that could have had.
Link to comment
Share on other sites

I finally got around to loading it, and it looks pretty nice. It does slow down noticably when there are more sprites on the screen, though. From 4fps down to about 2.5fps.

 

Are you rebuilding the display list every time through? I've tried that before, and the DMA just sucks too many CPU cycles to do that kind of stuff. It's okay when prototyping new code, but it just doesn't work for final code. So you can't get away without reserving some space at the end of every display list for as many sprites as you will need.

Link to comment
Share on other sites

I finally got around to loading it, and it looks pretty nice.  It does slow down noticably when there are more sprites on the screen, though.  From 4fps down to about 2.5fps.

 

Are you rebuilding the display list every time through?  I've tried that before, and the DMA just sucks too many CPU cycles to do that kind of stuff.  It's okay when prototyping new code, but it just doesn't work for final code.  So you can't get away without reserving some space at the end of every display list for as many sprites as you will need.

Currently the DLL is built once and is not modified. For each line I have enough memory reserved for the DL entry for the background up to X number of sprites, and 2 bytes for a terminator. I have a DLI on a blank line at the end, that writes the Dlist entries for each of the moving objects that falls on a lline and a terminator. (The game screen DL enties are written at startup and fixed since they do not change). It also still could be optimized a little since I am doing 5 byte headers, and writing some DList terminators when I do not have to (because the next sprite will overwrite)

 

Currently since it is a demo, the main not interupt portion is just updating X and Y cords and has a time killing delay loop and is not syncronized in any way, so if more cycles are being used when more sprites are being displayed, the loop probably takes longer and things slow down. This actually happens a little in my 5200 version, but the number of sprites on screen in the game is fixed 99% of the time.

 

Do you (or anyone know), is there a terminating sequence for the Display List List, or do I have to output a certain number of lines? What happens with too few or too many? All of the docs I have seen are not really clear.

Link to comment
Share on other sites

Currently the DLL is built once and is not modified.  For each line I have enough memory reserved for the DL entry for the background up to X number of sprites, and 2 bytes for a terminator.  I have a DLI on a blank line at the end, that writes the Dlist entries for each of the moving objects that falls on a lline and a terminator.  (The game screen DL enties are written at startup and fixed since they do not change).  It also still could be optimized a little since I am doing 5 byte headers, and writing some DList terminators when I do not have to (because the next sprite will overwrite)

Okay then, you are indeed doing it the "right way".

 

Do you (or anyone know), is there a terminating sequence for the Display List List, or do I have to output a certain number of lines?  What happens with too few or too many?  All of the docs I have seen are not really clear.

Maria just goes for as many scan lines as she wants, which is different between PAL and NTSC. To be "PAL-safe", just add however many scanlines worth of empty DLL entries are needed (I'm not gonna look it up). This won't do anything about colors or game timing based on vertical retrace, but it won't leave crap at the bottom of the screen.

 

I guess I better get my ass in gear and get to work on my 7800 project. Right now I'm working on a right-joystick-port driven monitor so I can do single step and breakpoints. I'm itching to get my game logic working to a demo-able state; it's been at least two months since I've made any progress.

Link to comment
Share on other sites

I've tried out both of these ROMs on my Cuttle Cart2.  In both I get a stable playfield but the sprites are moving diagonally all over the place.  Is this what everyone else is getting?  BTW:  I'm using the 7800_32K "bankswitching."

 

Rob Mitchell, Atlanta, GA

 

Yes, it's just a demo right now.

 

Mitch

Link to comment
Share on other sites

I've tried out both of these ROMs on my Cuttle Cart2.  In both I get a stable playfield but the sprites are moving diagonally all over the place.  Is this what everyone else is getting?  BTW:  I'm using the 7800_32K "bankswitching."

Its just a demo to test if the display routines were working. If you want to walk around and not do much...

bd7800.zip

Link to comment
Share on other sites

I just can't seem to get this game working on the Cuttle Cart. I love my CC2, but it's software isn't the most user friendly. Anyone want to do a step by step on how to make this game run? I can't get the CC2 to even recognize it!
In testing, I use the serial downloader option, since I need to be able to quickly test a new change. Otherwise, I think you have to add an appropriate line to menu.txt, run the menu geneator, and copy the menu.cc2 file and the game file to the mmc card.
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...