Cybearg

What if you replaced this: rem if the player sprite (car) touches the playfield... Game over, man. rem if collision(player0,playfield) then goto explode if !collision(player1,player0) then skipexplode rem rem skid the car if you hit the oil slick rem player0x=player0x+(rand&3)+2 skipexplode rem That's it, loop back. rem goto Main ... with this: rem if the player sprite (car) touches the playfield... Game over, man. rem if collision(player0,playfield) then explode if !collision(player1,player0) then skipexplode rem rem skid the car if you hit the oil slick rem if !direction then velocityx=velocityx-0.04 else velocityx=velocityx+0.05 skipexplode rem That's it, loop back. rem goto Main You save enough bytes by cutting out that one "goto" word and removing the rand, you actually end up with 11 bytes to spare, instead of just 10

Nice. Is there a practical limit to the resolution available? The only downside there is the size, of course, but there is a good deal of space available with 6 banks free. Also, it looks like you've got no_blank_lines there. Do you know if you've lost the missile because of it?

Oh, I forgot--aren't there no kernel options available for DPC+, no_blank_lines included?

That's awesome! Thank you, Atarius! ... Now if only there was a way to have no_blank_lines without losing the missile. There's got to be a way to reassign the memory locations that are used so that it doesn't result in the loss of a missile...

It's still an issue for the main reason that I can't increase pfres for DPC+ games. Also, the stack is only somewhat useful, from what I understand. It gives you a whole bunch of temporary variables, but DPC+ will be using that stack as well, so you've got to unpack your data so that DPC+ can use the memory locations. It's not multi-cycle memory storage like a-z, at least so I understand it.

Thanks for letting me know about the pfclear. It seems to be finally working, now. Ah, that's disappointing.

This one isn't so much a kernel question, but why does my playfield become a jumbled mess when I enable superchip bankswitching? This applies even when using the standard kernel.

In my personal opinion, rather than jittering the player back and forth, the oil slick should amplify the momentum of the car. So, for instance, if you were driving straight with no left or right momentum, there would be little if any difference, but if you were moving to the right, it would increase that velocity as if you jerked your controller to one side. But I'm guessing you don't have room for that.

That one works well! The difficulty seems solid to me from what I've seen. How close do you think you are to completion?

I get the same as loon with RC3, sadly.

Is there any danger to using those since, as RevEng says, they're slower and in the stack? Wouldn't that mean they're temporary? What are the addresses for those? Does DPC+ use the Superchip by default? If not, then can the SC be used to increase pfres up to 32 for square pfpixels?

Thanks for the answers. Disappointing, but good to know. Is there any reason to use multisprite in lieu of DPC+, considering that DPC+ seems to do everything it can do, plus more? Does DPC+ actually use absolutely every available bit of memory aside from the 26 standard variables, then? No unused bytes here or there? In follow-up to question #3, I'm not referring to pfclear/pfpixel/etc., but rather writing bytes directly to the playfield, as with var0 = %00110000 Is that possible with DPC+ and multisprite? If so, where do they need to be written to? EDIT: iespota, does that collision for the DPC+ actually work? I was under the impression that collisions, and other stuff, were bugged and hadn't been fixed yet. Is that not so, then?

That's what I would have thought, but then why aren't there any lines there when the game first starts?

I have a number of questions, so hopefully someone more knowledgeable than I can clue me in. 1. Is vertical/horizontal scrolling possible with DPC+? 2. Is there a list of DPC+ memory locations somewhere? 3. Since multisprite doesn't have any var0, var1, etc. listed in its memory map, does this mean that it's impossible to draw directly to the playfield? How does that work instead? 4. I know that hard collisions beyond player0 and player1 don't work in DPC+, but what about with multisprite? 5. Do players beyond player0 and player1 have missiles in DPC+, unlike in multisprite? 6. How much unallocated memory is there for the DPC+ and multisprite kernels that isn't being used for anything? 7. Can the titlescreen kernel be used in conjunction with multisprite or DPC+ to basically make a game that just uses bitmaps for backgrounds/playfields instead of relying on pfpixels? ... I'm sure that there will be more.

Did you find any explanation as to why the side walls have lines in them sometimes? At first, when you immediately start, the walls are smooth, but then they move in a bit and get those segmented lines partway through. Any idea why there is that inconsistency? It all seems very solid to me. Great timer graphics and I like the title screen. All very well done within the limitations. I noticed just one thing off--when the car crashes and the crash noise goes to silence, it isn't fully silent. There is a bit of electronic buzz, like it's not fully muted or something.

Thanks much to all! I've sent RevEng the latest version and I'll make sure to have what Gateway recommends. Thanks again!

Too bad. It would be pretty sweet to know that you can kick back and listen to the horrifying squeal of your game's working code.

Out of curiosity, Would you happen to have a copy of 1.1c somewhere? I can't find a link anywhere. I think the latest version is 1.1d, though, which DOES seem to work, so thanks, all. If you wonder why it is that I don't just use 1.1d at all times then, it's still because of that frustrating inability to compile Heartbreak (the game I'm still trying to finish) without a LINE --> complex condition detected error, which I would still love to know how to fix so I can compile freely with 1.1d instead of having to switch back and forth.

Sorry, I missed that. It DOES seem to work without crashing, but I still get the same strange error, plus that jumpman demo doesn't work, so there's still something off: Compiling S:\bataribasic\projects\RandomStuff\maryo.bas 2600 Basic compilation completed. bytes of ROM space left in bank 1 bytes of ROM space left in bank 2 bytes of ROM space left in bank 3 fs length $85 bytes of ROM space left in bank 4 3380 bytes of ROM space left in bank 1 4052 bytes of ROM space left in bank 2 4052 bytes of ROM space left in bank 3 fs length $85 2700 bytes of ROM space left in bank 4 3380 bytes of ROM space left in bank 1 4052 bytes of ROM space left in bank 2 4052 bytes of ROM space left in bank 3 fs length $85 2700 bytes of ROM space left in bank 4 What is this fs length $85 thing? I'd really like to get it sorted, as small compiling bugs can add up to a game-breaker at the worst time. Though apparently my crashes were due to me lacking something or another, but it's good to know that it's probably not just the multisprite.

Is that related to the problems I've been having? I've never used pfread before. I didn't realize that there were actually so few options for bB users. I was under the impression that the multisprite kernel was commonly used and well-documented, but apparently it isn't, and yet DPC+ is broken and buggy and has no sign of a fix on the horizon two years after its release? What is the bB community using if all these multi-sprite options are severely limited/broken?

Thanks for the link! I tried out your neat jumpman demo, but I got the same error as with my little attempt, so either it's the multisprite kernel that I've got or the batariBasic that I've got. Same error as before: fs length $85 bytes of ROM space left fs length $85 2416 bytes of ROM space left Unrecoverable error(s) in pass, aborting assembly! Errors were encountered during assembly. Hopefully someone knows what's going on, because I have no clue.

Instead of having to change anything, could you just adjust the numbers so that there are 2 minute numbers and 2 second numbers? Yeah, it's a little odd for a racing game to not have milliseconds but it'd pretty much guarantee no one would go beyond the highest possible score without any actual code being added.

Is there perhaps a link to a working demo of the multisprite kernel? I've searched through the forum a couple times now and there's surprisingly little documentation for it. Even Random Terrain doesn't really explain much about how to actually implement the thing. I'm sincerely hoping that I'm just being silly and not knowing what I'm doing and that it's not yet another frustrating issue with batariBasic. I've posted the files anyway, even though I don't know what the problem with them could be, since the multisprite kernel I've got here is a slightly bugfixed (see above) version while the game is pretty much empty. multisprite.inc multisprite_bankswitch.inc multisprite_kernel.asm multisprite_superchip.inc multispriteheader.asm multispritesuperchipheader.asm multisprite.h.txt default.bas default_4k.bas

Sorry, I've never tried it myself, I just know it's a thing. Hopefully someone with more knowledge can offer suggestions.

How much space do you get freed by cutting out those pfvline routines? Because if you had enough room, you could draw the line by writing full %11111111 to all the variables necessary to make it, then randomly choose a bit to start at and flip a number of bits determined by another random number.