ScumSoft

Looks alright, although I've always found it to be a bit painful on my eyes and hard to keep track of where the player is unless you carry an item. If you've been searching for a more elegant fading flicker effect, I would be more than happy to whip up some examples, if you'd like?

Tested, everything seems fine now.

Very neat! but you can't stop here, now you have to do the elites and gruntys as well

You can use bank1 for initializing the startup stuff, but it's limited in space to less than 100 bytes I think. Bank6 can be used for routines if needed, but this is supposed to be reserved for graphics only. If you place code here you run the risk of having it written over since this bank is writable. I have yet to encounter this though and I use it for my titlescreen which frees up space in other banks. [edit]Almost forgot, banks 2,3,4, and 5 are completely free for normal usage.

The DPC+ gives you 6 banks to work with, however bank6 is reserved for GFX data, so anything placed there has the chance to be overwritten without notice. Also you don't have to declare set romsize 32k when using the DPC+ as it sets the rom size to 32k regardless. The template I shared with you in the Atomic Meltdown thread should get things compiling right out of the box. Your not forced to use it of course, but it takes in mind all the current needed quirk workarounds to avoid future headaches. I recommend using that template and just filling in the needed areas as mentioned in it. There shouldn't be a need to modify any of the template code settings for even the most advanced DPC+ games to work. Sprites can be 192 visible pixels tall, 255 max. Also can be no wider than 16 pixels (using P0+P1 set next to each other manually) without flicker. Flicker will start showing as soon as a virtual player 2-9 is within 5 scanlines of P1, and thus with flicker you can get larger sprites but they look bad.

Looking great so far!

You've got a DF7FRACINC stack pointer bug, make sure you've got some null assignment such as temp1 = temp1 right after each bank declaration. I went to take a picture of the playfield streaking, but while hunting camera batteries for a few mins leaving myself dead, the game completely wigged out visually and I still can't find my batteries

Its a DPC+ Game and works only with the melody/harmony carts afaik

Piss off the author. Offer $32,767 instead of the $32,768 he wants. You could just say your counting system is zero based.

F6 12k rom? Are you lacking the DPC+ header info? It should compile to 32k always. What I posted in the Destiny WIP thread might help kick things off for ya. DPC+ Caveat list + Template

I like it so far however I get to a screen with a black hole on the right and it doesn't change after that. Did I win?

Fair enough I suppose, however there are only I think 2 major workarounds that you need for things to work proper. 1)Add temp1 = temp1 right after a bank declaration to fix the stack bug. This can remain forever and not impair your game or future compilers. 2)Set kernel_options collision(playfield,player1) is required or else the code won't compile and adds the new collision detection routines. Current other issue/bugs that I can recall offhand are: * Colliding with virtual objects 2-9 from the top or bottom have a 5 pixel leeway in them and will only trigger a P0/P1 collision upon impact. Check with Y position to know which Virtual Px you hit. * Taking a virtual player to Y = 0 will cause all other virtual players on the screen to temporarily adopt the X position of the Y = 0 player object. * A few bB commands are missing and will cause you to deal with things differently for now (This is major for you I know) * Stella and Harmony work completely different with ARM code, so things that look perfect on Stella during design may in fact not work at all on the Harmony. I think that's almost all of the current bugs and inefficiencies of it. The other workarounds are subject to the game being designed at hand. You could try porting over your maze collision demo and see how it works out, and that might reveal some more issues yet undiscovered. The following should be all you need for a DPC+ template.

Why wait? The dev kit is pretty much fully functional right now with a few quirks, but none of those are show stoppers I'm finding the DPC+ support to be well implemented right now. Most of the issues can be accounted for and worked around.

Players have a choice in how they control their character, how adept they are at manipulating their virtual counterparts determines if they succeed or fail, and that IS gameplay. It may not be the most robust gameplay experience, but your causing interaction and that leads to a subjective good or bad time. Dragon's Lair fits your description of a "Static Action Puzzle Toilet Paper Game" perfectly and yet you are still incorrect about this type of gameplay being a bad design. Expand the spoiler for a direct quote from wiki: A game that influential and successful in it's presentation and design cannot be a flawed concept! So sorry RT, but I must disagree with most everything you've pointed out. However this is not to say that companies haven't butchered this type of gameplay design to the point it's soured peoples opinions of it.

Well it's about time you got one welcome to the club, you won't regret getting one. I should also say just in time as well! ChargeDPC_bank1.bas.bin fixed the bounce issue completely, ChargeDPC_bank5.bas.bin bounces only when you move. [edit] Just thought I would also add that I've been working on a custom DPCplus.arm header which optimizes the bank6 purely as a display output buffer and not just as a fast data fetch area. Stella might one day fully emulate the ARM code, but right now it's completely useless for this other project of mine(it wont even look at the custom DPCplus.arm header). Having the Harmony cart which runs it flawless definitely opens a new door for some neat things, which also means once I'm done you can see first hand how it runs and help ME test it

Yeah all the fetchers can be set independently for some interesting effects. However your fix didn't fix the bounce, and now the score background is yellow

Currently on my end the player will damage if you hit the playfield to fast, and receive no damage on slow impacts. I'll try scaling the damage and see how it plays, if it seems good I'll keep it. Thanks for the suggestion.

Space invaders is the #1 game my family recalls from that era, so I thrice this opinion.

I don't mind since I own a harmony cart, if you don't mind sharing the source at this time I'd be happy to do some testing on this end. The background raises 1 scanline then drops 1 scanline, so it sounds like an index problem that your DF6FRACINC is not set properly, or that your bkcolors table is off by a byte. Stella won't show these issues since it uses it's own DPC+ routines and does things differently, what you need is a real cart

The knight crash has been fixed, however the background bounce is indeed still there.

Then your already optimized and won't greatly benefit from what I suggested then

Funny you mention that game as it's one of my favorite nes titles. However this game won't give due justice to that one I would say thrust is much more akin to Solar Jetman that any other.

Crashes to black screen, my game started this as well but the older builds work fine. I found that it dislikes pfhpixel being set in some places, need to isolate why. "but only the backgorund" is literal for both, so I meant that only the background was bouncing for those two. However I do have good news! I've just saved 10% on my code by switching to GEIC...I mean placing all drawscreen and return calls to subroutines per bank. ; ***************************************************** ; * BANK # ; ***************************************************** bank # rem *** Bug fix for now temp1 = temp1 rem *** By calling these two routines instead of inlining, you save lots of rom space DrawBank# rem *** Set reflect for P0, calling drawscreen without setting REFP0 defaults P0 to facing right rem *** This fixes that problem, however REFP1 doesnt seem to work right now if Reflect then REFP0 = 8 else REFP0 = 0 drawscreen rem by placing these in this order you benefit from the return below RetBank# rem *** instead of placing returns all over your subroutines, place a goto RetBank# instead rem *** the savings add up really quick return Replace the hash sign with each bank number, and place this at the start of each bank. also you might just comment out my Reflect bit usage if not needed. Would you entertain the idea of using the stack function to gain more ram space? If your using a var which wont change often, say a var to know which wave your in, then push that to the stack, then pull when it's time to check it. Stack 200 push WaveNum rem WaveNum is now in stack 199 rem do some stuff rem retrieve WaveNum stack 199 pull WaveNum

081011.bin bounces, so does 081411.bin, but only the background. Players seem fine, however on 081411.bin the game crashes on the Harmony as soon as the enemy knights appear on the screen, 081011 does not crash.