ZackAttack

The change is easy to make. I just need to know that it's the right thing to do first. I think I'll take a poll to see if anyone even would benefit from such a change.

The graphics engine now supports bank switching! Since the platforms looked like big chunks of land floating in mid air I figured why not make them steel instead and add a couple rocket engines for good measure. Everything is better with rocket propulsion http://youtu.be/COyXmOEVllc

Here's what 2600bas.bat contains. dasm "%~f1.asm" -I"%bB%"/includes -f3 -l"%~f1.list.txt" -s"%~f1.symbol.txt" -o"%~f1.bin" | bbfilter Sure I could easily adjust it to use lst and sym extensions respectively, but that won't benefit anyone else besides me. Maybe I need to figure out who currently maintains bB and visual bB and ask them directly. It's surprising to me that this hasn't been brought up before. Could it be that no one is using the debugger for their bB programs, or am I just missing something?

I grabbed the source for princess rescue and built it locally so I could test some changes to how stella handles debugging banked carts. This has raised the following questions. 1. Why aren't the lst and sym files saved in the bin folder next to the bin file with lst and sym file extensions? Is there a setting to make this happen? 2. Is there a way to keep all the extra labels from being defined in the lst file? For example, the location at 1eba should only have the .MarioJump label instead of all 3 of these: 3487 1eba . 3490 1eba .MarioJump 3493 1eba .L0323 ; player0:

Dpc+ offloads some of the work onto the onboard ARM core. You need a harmony cart to test dpc+ games.

Multiplying by 2 can be accomplished by a left shift (ASL) and is most likely faster than adding a memory location to itself. You could verify this with stella by simply implementing both solutions and then comparing the cycle count in the debugger. If you put a label just before and just after each section of code it should be easy to determine which asm instructions correspond to which basic statements.

If you're interested, I could definitely used some assistance with the sound for my current project. Supporting 8way scrolling with single pixel resolution takes up all the CPU time during the picture scanning, but there are plenty of available cycles during overscan and a ton of ROM space available. I would be interested in any ideas you may have.

I've definitely seem some occasions where holding the button just continually fires the moth instead of it hanging out in front of you. Seems to happen most often when you take damage while holding up and button. I miss having the variety of enemies that the previous build had. Maybe you could introduce new enemies each time you add a butterfly to the tree screen. It might help hint to the player that should keep collecting more fruit even though they're going in circles. Just a thought. Either way I still enjoy playing it.

Each bank has to have it's own "play" routine because that banking scheme only allows a single bank to be in scope at a time and you need to access both code and data simultaneously. The routine could be enhanced to do the bank switching itself to avoid the small delay between sound clips. However, the delay I was referring to was the one that's embedded in the play routine between each sample. Also, you shouldn't get too optimistic about what could be done together. It's possible to have some very impressive sound or very impressive graphics, but having both at the same time isn't all that feasible. DCP+ and assembly can be used to produce some very impressive results but then you would lose the ease and productivity of programming in bB. If that was something you wanted to pursue I'd start by checking out the asm tutorials on here and then check out the blog SpiceWare is working on about programming DCP+ in assembly.

I'm glad I was able to help. That demo is really interesting and it ran a lot longer than I expected it to. If you look at the assembly you'll see that there is a fairly large delay between each update to the AUDV0 register. I wonder if the extra cycles could be used to either add another channel, support data compression, display some dancing sprites, or maybe even a combination of them. Of course that would need to be done in assembly in order to keep the timing correct. I wanted to build a 512KB banking scheme for the harmony but I could find documentation on it. I ended up just creating a new custom banking scheme that can support up to 256MB. Once I complete my game and finalize the hardware I plan on making it available for others to use. That's going to be a long time from now though.

Finally got a chance to try the latest build. I only beat the boss once. I thought it crashed until I read your post and didn't have time to try again. Here's some more feedback. 1. The only enemy I encountered was the wasp. Is that all you get on level one? 2. Using a sprite for the fruit is a huge improvement. Stands out much better now. 3. There is some inconsistent behavior when firing the moth. Sometimes pressing fire is all that is needed, other times you have to hold a direction too. I may not fully understand the controls. 4. I think you should force the player to remain on the screen when the butterflies are pulling the tree out of the ground. Looking forward to your next update.

Due to the way that negative numbers are stored you can just have a single variable to hold the sprites velocity and then simply assign the velocity to the REF register as well. I think you'll find this code is concise and easy to read. It also allows you to control the speed of the sprite which I've demonstrated in the attached bas file. Of course you could do a lot more with the speed such as increasing enemy speed when the player is inline with it. ;******** DONE ONCE ON START/RESTART ********* ; Use dim to give 'a' a friendly name. Any available var can be substituted in place of 'a' dim HorizontalVelocity = a ;Initialize the velocity. Postive means moving right & negative is moving left HorizontalVelocity = 1 ;******** DONE EACH FRAME ********* ;Move the sprite player0x = player0x + HorizontalVelocity ;Change velocity if player0x > 150 then HorizontalVelocity = -1 if player0x < 10 then HorizontalVelocity = 1 ;Update sprite's reflection REFP0 = HorizontalVelocity default.bas

Another option would be to add a frame buffer and a GPU. Something similar to what the NES has. I'm sure some purpose built graphics hardware would produce better graphics than an overclocked 6502. If you think about it, a 6502 would need to run at over 5 times the speed of the TIA and have a huge amount of RAM to update the TIA once per color clock. It would be much more effective to just have a frame buffer and update the COLUBK register once per color clock with it.

Ok, try this one. You can get rid of ALL of the dim statements because I changed the routine to use stack memory instead. I moved the data to the beginning of the asm file. Make sure it is included first in the bank before everything else. There is room for up to 15 pages (3840 bytes) of data. Just make sure to modify the CMP at the bottom (see code below) if you use less than 15 pages. I didn't address the scanline count though. That's going to be too time consuming and I need to get back to work on sonic. CMP (#>HelloStart + 15) ;<--- Change this if using less than 15 pages voice.asm

I'll see if I can figure out how bB works enough to throw something together real quick. It shouldn't be too difficult to get a consistent line count.

I think the bB page is correct as it is now. An include statement inside the asm statement is a completely separate thing from what I can tell.

It's not pretty, but it works.... Really it should be refined further so that it can be included as a bB library like fixed_point_math.asm. Further work is also required to allow a smooth transition between rendering graphics and outputting audio. voice.asm default.bas

I think you're overlooking the fact that dasm recognizes include so the following is actually a line of asm technically. include "HelloWorld/test.asm" I assume dasm is what is actually performing the step of loading that file and inserting it's contents inline.

I'm not familiar with the digitizer, but if you post the asm and bas files I might be able to help.

That's not going to work because the asm file is defining the physical(ROM) location of the code which is not compatible with the asm the basic source is being transformed into. You could try trimming the test.asm file so it doesn't have any seg or org statements, but even then I think you're going to run into problems with what you're trying to do. In order to get this working you would probably need a very good understanding of assembly programming. There is also a good chance that the generated test.asm is going to corrupt the state of the bB code. So even if you get it to compile it will likely crash.

I'd say the skipping gotos has a speed advantage because the!_sound0 condition can be done once at the beginning like you have in the original post. So you'll end up with less comparisons in the worst case scenario.

I'd start with a basic finite state machine (FSM) that has 2 states, traveling and navigate. In the traveling state the AI agent would continue to move in the same direction until it aligns with the PF, at which time it would transition to the navigate state. In the navigate state I would map the A.I. agent's location to the PF pixel/block that it is currently aligned with and then look at the surrounding pixels (top, bottom, left, right) to determine which directions it can go without colliding with a wall. Once a new course is chosen it would transition back into the traveling state and start the process all over again. The selection of available directions could be made at random or use an algorithm to chase/flee the player.

Nice job. I played through a couple times and didn't see any bugs. I wish my game was progressing this quickly. Have you considered making the boss behave less random? Maybe he could move in a preset path and then randomly choose between a few different attack types. Like moving left to right at the top of the screen and then swooping down at you. Maybe he'd only take damage when he's in certain states. It could make it feel more boss like. Assuming you haven't already run out of resources or moved on to the next project.

Nice. Just wrap it in an asm statement and you've got linear scrolling speed control with a single variable in bB.

I think this is a great approach if the speed will be constant. If the speed will be changed at runtime there might be a more linear way to do it with a single variable.