[Atari 2600 Homebrew Games Completed/WIP in 2021]

3 hours ago, ZeroPage Homebrew said:

Ah yes, I was thinking this is something that I missed from 2021 as this is the 2021 thread, my mistake.

 

I haven't added it to the 2022 list yet as it hasn't yet been shipped, there's no binary and there's no video footage of the game. Once one of those qualifying things happens it will be added to the Atari 2600 2022 list. ?

 

- James

 

 

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.

[Assembly language VS batari Basic]

2 minutes ago, Gemintronic said:

 

Okay.  A little creepy that you bring up my nickname on other platforms.  Public knowledge but in this context it sounds like you're trying to scare me.

 

Like I said: I just want to understand your comments.  But, that appears to be too much for you.  Sad.

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

[Assembly language VS batari Basic]

3 minutes ago, Gemintronic said:

 

You need to work on your communication skills.  If you can't explain yourself in a respectable manner then your point is lost.  I still have no idea why you chose to reply to my comments in this thread. 

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?  ?

[Assembly language VS batari Basic]

23 minutes ago, Gemintronic said:

Please clarify yourself and tone your attitude down.  We're all AtariAge members looking to appreciate Atari and fellow enthusiasts.

And, that's why you brought up this conversation, right? To appreciate?

 

Let it drop.

[Assembly language VS batari Basic]

23 minutes ago, LatchKeyKid said:

I can't tell if you're actually angry or just joking.  I took the "mere mortal" comment as the joke it was intended to be FWIW.  I suppose if you truly have divine powers then you could theoretically be offended but I'd question why you're using your supernatural abilities exclusively to code for a classic console.  It seems like there are so many better uses...

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.

[Assembly language VS batari Basic]

1 minute ago, Andrew Davie said:

I'll show you mine if you show me yours

 

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. 

[Assembly language VS batari Basic]

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.

[Assembly language VS batari Basic]

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

[Official Home for batari Basic]

@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.

[Quake on the GBA]

2 hours ago, DEATH said:

On SNES, games with SuperFX Starfox, Doom or even Virtuaracing on Megadrive, the console works like a graphics terminal. The size of the screen also depends essentially on the amount of data that you can transmit during the blanking period rather than on the power of the SuperFX

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

[DEMO - Impossible Mission (not WIP or Game)]

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.

 

[ARM-based games and the Flashback 9 - when will AtGames offer a firmware upgrade for those???]

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

[Best and worst transitions into 3D]

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

[Best and worst transitions into 3D]

33 minutes ago, Austin said:

The tech was there, the problem was--and I'm pretty sure Romero himself has stated this in interviews--that it just wasn't fun. So, the deliberate choice was made to focus on fast, twitchy action instead.

 

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.

 

 

[Best and worst transitions into 3D]

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.

 

 

 

 

[Change CTRLPF Mid-Screen.]

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.

[Is their a market for new games on old platforms?]

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.

[Counting CPU cycles and RAM usage]

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

[Technique for Pitfall style music/effects coding?]

It's all right there.

 

That table is only storing frequencies. The control and volume values are hardcoded

 

[1942 WIP]

Never mind.  ?

[1942 WIP]

1 hour ago, splendidnut said:

Might as well show a teaser screenshot:   (Ignore the background color change line....and the fact that it's a bit garbage... this mainly was a hack to let me see when one of the kernel labels was being hit... It may not be feasible to keep around.)

Did you remove background color changes completely?

 

Does 1942 use the background color feature?

[Boom! (Atari 2600)]

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

[DEMO - Impossible Mission (not WIP or Game)]

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.

 

[DEMO - Impossible Mission (not WIP or Game)]

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. 

[1942 WIP]

13 minutes ago, Al_Nafuur said:

I removed ACE from the PlusCart firmware, because it wasn't really used back then.

 

But ACE support has been rolled out earlier this year:

https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/source/STM32firmware/PlusCart/Src/cartridge_emulation_ACE.c

 

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.)  ?