orange808

I don't understand this release. Did I miss something? No demo, no screenshots, no video, no worthwhile gameplay description, and no unveiling on ZPH (A YouTube channel physically playing a game can act as a standalone introduction and substitute for other media). To be perfectly honest, this reminds me of Nothing But Trouble hitting theatres with no critic screenings or a Carrot Top movie going direct to video. I feel like the dev doesn't want me to know what the game is like. Never good. I am not the only one that will feel this way. I'm just the one that said it out loud.

Your original handle here. I've literally been reading this forum since it started.

My last post simply echoed another comment. Yet, Mr The Loon, (how long have I been lurking, anyway?), I must earn mah street creds before I can speak, right? ?

And, that's why you brought up this conversation, right? To appreciate? Let it drop.

Not sure what you're getting at. Care to clarify? FWIW, how I use my own free time is my business. Also, I can walk and chew gum at the same time. ? Maybe the reason my hobby projects aren't done is because: I've got other genuinely important things to do.

To be perfectly honest, you're a genius and I especially wouldn't ever show you something that isn't presentable. The same way I wouldn't touch the keys if Stevie Wonder was in the room.

Still singing the ol' AtariAge ARM "greatest hits", I see. If my project ever gets finished, you're going to sh*t your pants and have a seizure. Just know I'll be laughing at you when you complain. ? And, if you try to sell my efforts short with that "mere mortal" sh*t, I'll embarrass you.

https://atariage.com/forums/topic/281105-open-source-c-project-template-now-available/

@RevEng Out of curiosity, do you remember how much ROM is left on the bB DPC+ ARM side in main.c? Might be nice to have the ARM handle common math calculations. For instance, in theory pfread makes a lot of sense as is; in usage, not so much. Devs are often polling a VCS object's coordinates and the ARM can handle ((foo-16)>>2) much faster. If space allows, maybe I can add little something. With additional functionality dropped into main.c, should be able to drop new commands into commands.c. Anyhow, just got to thinking when I saw another post about the playfield.

The SuperFX can and often does run in parallel with the CPU. ? Clone TIA Atari 2600 compatible expansion modules for the ColecoVision and Intellivision are better examples of hardware that transformed a console into a de-facto "terminal" when seated in the cart slot, but the word "terminal" is usually wielded as a clumsy smear in this context. Doesn't matter anyhow, because those weren't game carts. I can't think of any individual game cartridges (off the top of my head) that completely replaced the internal hardware of any given console. Investigate for yourself. There are tools to see what's going on: https://github.com/devinacker/bsnes-plus

No. I don't have code handy to do it. You'll have to use inline assembler, point a data fetcher (storing #24 as the C_function "DFxHI" will spit out data) at your playfield color data, and grab the information. After that, you'd have to use a logical AND to get at that unused bit. You'll have to look up the data table location in the assembler output of your code. And, now that I type how to do it, I realize I took you way out into the weeds. I apologize.

AFAIK, MiSTer doesn't play ARM enhanced games. I'll stop there.

I'll correct myself. No mouse look in UU. Oh, the horrors of the levitation spell.

Point taken. On the other hand, I found it hard to tell which way a clump of four pixels was facing from across the room. There's also the problem of looking around and understanding the environment with only keyboard input. Although, I experienced at least some degree of freedom and stealth playing Ultima Underworld, but that was a considerably more refined iteration of what Castle Wolfenstein did with the benefit of mouse look. Regardless, Wolfenstein 3d is a complete departure from Silas Warner's designs. It's an entirely different game with the Wolfenstein name stamped on it.

I disagree. The original stealth action series reimagined as a straight forward shooter was a bit of a head scratcher for me. The legacy Castle Wolfenstein series ended with Return to Castle Wolfenstein. Don't get me wrong. Wolf 3d is a fun game in its own right, but it's not a 3d reimagining of anything Castle Wolfenstein. The Thief series, Metal Gear, and Splinter Cell ultimately picked up Silas Warner's (RIP and much respect) mantle and carries the ideas forward into 3d. In Wolf 3d's defense, the tech wasn't there to make a stealth action game and they needed something you could shoot without offending people; Nazis were the perfect foil.

You need a custom kernel for that. In theory, you could mask ordinary sprites without any special NUSIZxx properties (no stretching or repeating) in software, but you probably need to use ARM to do that in a practical way. The TIA doesn't tell you where or how you collided with the playfield--only that you did. So, you have to build your own representation of the playfield and compare the sprite. That's going to be expensive. I think bB DPC+ kernel could be hacked to hammer CTRLPF by giving up half the background color changes, but you'd be wasting a lot of space. Repurposing half the background color data would use entire bytes to store the playfield priority status on every other "line" (at your chosen playfield "resolution") and the condition is logically boolean.

FYI, 8 bit unity appears to be BSD. That most definitely is not GPL. https://github.com/8bit-Dude/8bit-Unity/blob/main/LICENS A nice clean choice. Copyleft licenses can be tricky business.

That sounds tricky, because you really want to hit the motion register on every line to draw vines. No bB kernel for that.

It's all right there. That table is only storing frequencies. The control and volume values are hardcoded

Never mind. ?

Did you remove background color changes completely? Does 1942 use the background color feature?

Might try mapping an action to a fast double tap on the joystick.

P.S. Another hint: One of the bits for the VCS colors is unused and has no effect on what you'll see on screen. At the cost of more cycles, you could isolate that bit and have a "floor" anywhere you want and any color you want.

Given that it's bB, I assume you have a table somewhere that specifies playfield colors and that has some kind of direct relationship to the scanlines. Maybe that could reused as a lookup table for "gravity" collisions. I assume platforms are stationary and the game works by drawing new "screens", so you'd probably want to add some sort of logic to correct the player when near the platform (maybe using a bitwise AND logic instruction?). There's really no time to loop while "falling" and make proper checks one vertical color clock at a time. You could detect collisions before they happen. So, if you detect a collision at a fixed polling position below your player's avatar, you wouldn't want your game objects to "land on the ground" at different distances from the platform. Maybe you could apply logic to place the game object directly above the ground when the platform color is found, based on polling the next planned "y position" for the "falling" game object? Above the player, if necessary, gamers are much more tolerant of seeing their avatar's head get pushed out of a ceiling after contact. So, you might be able to catch collisions on the bottom beforehand and check above with hardware collision, forcing the player back down after colliding with playfield. Although, using hardware collision to force the player down may not be necessary and it wouldn't work with the furniture.

Thanks. I don't have a PlusCart to test, but I heard back that Strong ARM ACE had some issues during a test. I don't know if the cart in question is on the latest firmware or not. I'll message you if it doesn't get resolved. (And I'll stop hijacking your game thread.) ?