Fort Apocalypse
-
Content Count
1,599 -
Joined
-
Last visited
Posts posted by Fort Apocalypse
-
-
We don't know that Atari have been motivated to do anything.Curt mentioned that something was in the pipeline: "what was being developed for 08' as an advanced follow-up system has been moved up to the front burner and is being worked on now in place of the original FBP design"
I am still pro-Atari and definitely pro-Curt, but it was a seriously bad decision to not give anyone any insight into what is coming. One of the absolute best ways to generate revenue is to create buzz. No talk = no buzz = lower revenue for Atari. If there is a competitor that Atari is afraid will steal whatever secret they have is, then don't say anything meaningful, but least say something and acknowledge the fanbase. It doesn't even have to be good. Just give us an empty statement every two months like "the greatest thing since sliced bread" and at least we can sit here and try to pick apart the statement for some hidden meaning of "sliced bread".
-
need a flashback seeing how I missed out on the FB2 due to lack of funds.What's stopping you from buying a FB2? Or did you mean FB2 portable?
Odds are the next flashback (or whatever it is called) will be more expensive (but not much more though).
Not like anyone cares about my theories but here's the latest:
* atari 2600 console with cartridges that contain about 40 games each (a few best sellers, lots of "average" ones, a few homebrews, several prototypes/new games) OR
* atari 2600 + atari 800 console with cartridges that contain about 40 games each (fewer homebrews/new games than it would be if it was 2600-only console) (this is more likely considering what Curt has said previously)
And would be:
* packaged with 2 joysticks again
* have no paddle/racing games (no unlockable games like the FB2, but there would still be easter eggs)
* keyboard connection can be easily hacked on if supports 800
This model makes the most business sense, and Atari/Infogrames cannot take chances at this point.
Reasons:
(1) only having an atari 800-based console would sink like a rock
(2) portable is too expensive to make
(3) USB load is too prone to legal and support issues
(4) emulator-based console is too expensive and there are legal concerns
-
Do you mind checking this out on a real 2600 to see if it flickers?Sure thing, but it won't be tonight.
Michael
No problem! It might make more sense to just wait until the game is closer to completion anyway. I'm sure that it could get more noticeable as I'm adding more logic to it.
-
Probably not 4 on one line, but two on a line stacked on top of each other would be doable. It would require that the 6-digit score be turned off, though.That would totally rock! I wouldn't mind at all that the 6-digit score get turned off. If there is anyway to also fit colors into it, that would be best, but even a single hardcoded color would be fine!
-
Sorry to bump, but any chance for an AtariAge wiki? TIA!
-
The minikernel is complete and ready to use.That's totally awesome! This definitely help out a ton of games!
Any chance you might be able to do a 4 player version (4 2-digit scores)? If so, I could really use it.
-
Do you mind checking this out on a real 2600 to see if it flickers? I switched to reuse missile 1 for the flag (both flagpole and flag) and dropped the pit since you set up a nice looking pit that I can just check x and y to determine if it is in the pit.
Here is the one with the latest changes (no more compile error):
-
Also, if the right half of the track will always be a mirror image of the left half, then it might be possible to create a customized version of the standard kernel that doesn't draw an asymmetrical playfield, and maybe that uses a ROM playfield (like the multisprite kernel) instead of a RAM playfield. If that could be done, then you could get a higher vertical resolution for the playfield, and extend it all the way to the edges of the screen, which should let you draw an oval track.Michael
Man, that would be totally awesome! I think a symmetrical playfield would be totally fine, and getting a higher vertical resolution would be really great for for better looking turns and for an oval track! Let me know if you think you might have time to help with that or if you could give me some pointers to how it could be done. I wish I had your asm programming ability! (Unfortunately between college and years of raising children, my mind is even less of a steel trap than it used to be. Even before that it was just small mouse trap.)
And thanks for helping me figure out the paddle issue! (that was an artifact of me trying to get it to work with multisprite, which of course never would work!)
-
Could anyone help me figure this out? TIA!
---------- Capture Output ----------> "C:\Atari2600\bB\2600bas.bat" C:\Atari2600\projects\ultindy500\ultindy500_0.1.bas
2600 Basic compilation complete.
DASM V2.20.07, Macro Assembler ©1988-2003
2600basic_variable_redefs.h (47): error: EQU: Value mismatch.
old value: $0090 new value: $00d7
2600basic_variable_redefs.h (49): error: EQU: Value mismatch.
old value: $0091 new value: $00d6
bytes of ROM space left
2600basic.h (34): error: EQU: Value mismatch.
old value: $00d7 new value: $0090
2600basic.h (35): error: EQU: Value mismatch.
old value: $00d6 new value: $0091
2600basic_variable_redefs.h (47): error: EQU: Value mismatch.
old value: $0090 new value: $00d7
2600basic_variable_redefs.h (49): error: EQU: Value mismatch.
old value: $0091 new value: $00d6
2367 bytes of ROM space left
2600basic.h (34): error: EQU: Value mismatch.
old value: $00d7 new value: $0090
2600basic.h (35): error: EQU: Value mismatch.
old value: $00d6 new value: $0091
2600basic_variable_redefs.h (47): error: EQU: Value mismatch.
old value: $0090 new value: $00d7
2600basic_variable_redefs.h (49): error: EQU: Value mismatch.
old value: $0091 new value: $00d6
2367 bytes of ROM space left
--- Unresolved Symbol List
Fatal assembly error: Source is not resolvable.
> Terminated with exit code 0.
I know that value mismatch usually means that I'm trying to set something with a value type it doesn't accept, but I can't see in the program where it is happening.
Program is (note- this is different than the other file I posted previously in diff topics with same name):
-
Awesome! Thanks, Michael!
I saw Batari had posted about my bug in the player 3 y coordinate setting that was causing it to "disappear" (go off the screen) also.
-
It's not a big deal, really. I just wanted to be able to start all of the cars off on a vertical line (actually 4 cars, a flag, and the pitstop are all on the same scanline, but the pitstop (player 1) does not flicker and the rest flicker badly). I'll start use imaginary horizontal start/finish lines instead of vertical ones.Are you sure you mean vertical? There should be no flicker in a verticle line:
X
|
X
|
X
|
X
But in a horizontal line you would have lots
X-X-X-X
Just checking...
I'm not really sure why it is flickering so much actually. I changed the sprites to not be on the same vertical or horizontal (at least as far as I can tell - maybe there is some overlap - don't know. Posted the code and bin here
Edit: Actually Michael figured it out in the other topic!
-
Better?Oh yeah. They rock!
-
Would use the internals of the paddles to handle the x and y axis, like a gun turret.
I would bet that this idea came up in the 80s and was shot down because it was too hard to do. Or maybe someone else already thought of it. But I came up with it a few days ago and thought I'd share it. Feel free to use this idea and build one yourself. By doing this. I'm releasing the idea for full public, private, and commercial use.
But I'm probably not going to actually create one.
-
Unfortunately it is the case. If you really want to use paddles, though, you might be able to do it with some ASM in the VBLANK routine.Could anyone provide some sample asm code that I could include within a subroutine of batari basic to do this? Unfortunately my eyes still glaze over with asm. If not, if anyone could point me in the right direction that would help.
In addition, it would be super awesome if it were added as the first (and only?) kernel option for multisprite in a bB 1.1 release, as not only would it allow people to more easily write 4 player racing games, but 4 player pong games with 2 balls (ball and missle), a warlords-like game (without the bricks, since there is no pfread or pfpixel in multisprite kernel), 4 player planetary defense, and you could build a new paddle-based turret controller and shoot at 6 sprites at once (by using a blinking ball and missle for the targets).
-
This is my very sad Friday night handiwork. Thought someone might find this funny because it's so bad.
-
Unfortunately I still can't get it working.
D'oh, I think I see your problem! "readpaddles" is a kernel option, but you're using the multisprite kernel, and the kernel options don't work with the multisprite kernel, just with the standard kernel.
Michael
Does that mean I can't use paddles with the multisprite kernel? That would suck.
-
Note I'm using Stella 2.3.5 on Win XP and bB 1.0 (at least that is what bB README.txt says).Yikes! Scared me for a while there, hoping there wasn't a bug in the flickering routine (that is, other than the known bugs that are already there
)I think the problem lies here:
if paddle < 38 then p3x =p3x - 1 : if p3x < 28 then p3y = 140
I'm pretty sure you want p3x = 140 at the end of that line. p3y=140 would move the third car off of the visible screen.
Doh! Thanks for catching that. Man I suck. Thanks, Batari!
-
Better?
-
Here's a proposed label. I'd much rather have a drawing of some guy with a paint brush running from something (away from the observer) with a wierd robot and nuclear vial over his head. But I can't draw that well.
-
Unfortunately I still can't get it working.
I tried what Michael said and what Stephen said and all paddles always equal 0. I even tried mapping keys to the paddles, which I'd rather use since it is a 4 player game and I'd like to emulate more than one paddle at once if possible, but that didn't work either. I made sure controllers were both set to paddle in the Stella green screens and reloaded the rom also. Tried starting with -bc paddles and saw that it was set to paddles in green screen which was good, didn't work, I tried reload and didn't work.
Attached is the source and bin I'm having trouble with. Stella 2.3.5 and bB 1.0.
(note: this is the same that I just posted in the other thread about the player 3 sprite issue)
Thanks in advance!
-
Note I'm using Stella 2.3.5 on Win XP and bB 1.0 (at least that is what bB README.txt says).
-
Player 3 disappears when using multisprite kernel and you move it too far to the right horizontally. If you move it to the left, it is no problem. Wierd! Attached is bin that shows this bug in Stella. (Who knows- maybe it is a stella problem?)
Leave paddle emulator off (so paddles all = 0) and try the following (this is not a working game - for now it is just a demo of the strange behavior). I actually get it while in both (r/l) paddle mode (but for some reason no paddles work for me still).
Also, flickering seems to be bad even though the players aren't on the same vertical scan line. If you have an answer for that too, it would be much appreciated!
-
While what SeaGtGruff said above will work, it means you'll have to manually do it every time the ROM changes (ie, when it's recompiled). However, if you're a programmer working from with a development environment, you'll probably be constantly recompiling and testing. Having to manually change the ROM properties in this case is very annoying, and is exactly why the commandline arguments were added in the first place.The correct usage would just be '-bc paddles'.
That's an excellent point, and the command line option is good to know.
This was a much requested feature a few years ago. Since I didn't personally develop ROMs with Stella, the thought never occurred to me to be able to change properties dynamically. To get around this, some people were even ingenious enough to create a script that recalculated the new ROM MD5 and rewrite a new stella.pro file, just to get the ROM to recognize the previous properties. I can see that being a PITA. I'd like to think I've learned my lesson on that one, since damn near everything in Stella is now configurable from both the commandline and UI
Thanks, Michael and Stephen! Will give it a try!
-
You can't have 5 independent sprites on the same line without a lot of flicker. But you *can* have up to 6 non-independent sprites on the same line without any flicker, if you display 3 copies of player0 (with NUSIZ0), along with 3 copies of one of the other players. Of course, that means the copies will have the same colors and shapes as each other, and will move together as if they're in formation.Michael
Thanks, Michael. I was hoping there was some cool trick to limit the flicker, but that's just me wishful thinking!
It's not a big deal, really. I just wanted to be able to start all of the cars off on a vertical line (actually 4 cars, a flag, and the pitstop are all on the same scanline, but the pitstop (player 1) does not flicker and the rest flicker badly). I'll start use imaginary horizontal start/finish lines instead of vertical ones.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Garry Kitchen wannabes, here's your chance
in AtGames Flashback and Portable Consoles
Posted
I think there is a good chance that the new flashback console will support the 2600, and even if there is a glimmer of hope that it might, and if the cartridge format that they choose is actually just an encased memory stick, or even in the very remote chance it supports USB, then there will be a lot of people that will be interested in new homebrew games for the 2600.
That said, for those that aren't aware (there may be a few) Batari Basic is a really great way to get into Atari game development, and you can create some pretty neat games with it (it's not just a stepping stone to asm anymore). If you are interested, please check out the Batari Basic (bB) forum in AtariAge: http://www.atariage.com/forums/index.php?showforum=65
There is a really great tutorial to get you started and a really great page for reference when you start writing code. Folks like SeaGtGruff (Michael), batari (Fred), and Curtis on the bB forum are always helping people out. It has been really fun hanging out with those guys and learning how stuff works. Maybe you might like it too.