RevEng
-
Posts
7,607 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
If a basketball player is shoots 60% from the free throw line, there's a probability of 6/10 that he will make his next shot from the line. However, if someone shoots 100%, he is guaranteed to make his next shot. Of course, you can have the 60% guy get a few in a row, but it will average out to that.
You messed up in understanding your own analogy.
If he shoots the ball at 100% of his full power, like a digital control, he's going to miss every shot. He knows the state of power he's using a priori, and yet that knowledge won't help him sink one basket.
If he shoots the ball with a lower percentage of his full power, he's going to sink a lot more, despite the fact that he doesn't even know the exact percentage of power he's using.
In all earnestness, you need professional help. Playing these games on a forum is harmless enough - it's not a war as some have declared - but every day you engage in it, is a day you're ignoring dealing with your issues.
-
6
-
-
Nice start! Can't wait to see where you take it.
Any chance to delay that COLUBK write so it doesn't happen on screen?
-
Who is this? Longhorn selling on Ebay now?
...
They had a few other Atari-related stuff:
Just a shot in the dark, but maybe it's AA member pags35.
-
...You can do this all the way to the bottom of the screen, so you can easily have something like 8 Zombies on the same screen without any flickering, as long as they don't share the same scanlines.
Also, you can use the missiles and the ball to draw more characters if these objects are not being used for other things (you'll need at least one of them for the bullets) and the characters' graphics are sufficiently blocky. So yeah, I agree that this game is perfectly doable on the 2600...
For sure. And even on the same scanline you could use player copies or the galaxians RESPn trick. The zombie hordes would be shambling toward the player, so moving together as a group wouldn't be a big deal.
-
Looks to me like it's based on SFCave...
http://www.youtube.com/watch?v=xWCmK6i-t_c
...which in turn inspired a number of games, including Thomas Jentzsch's Cave 1k.
-
-
The problem is definitely with JLoop. The hex for the opcode has zero for address bytes.
The 22.JLoop is happening because bB actually uses a . in front of the basic label names when it generates the assembly. But when dasm see's the .JLoop in a macro, it thinks the label needs to be renamed to be unique.
It you restructure your code to use inline assembly and to use "jmp JLoop" instead of "jmp .JLoop", and define the JLoop label within an inline assembly block, I think it will work.
-
... COLUBK = $C6 COLUPF = $26 player0x=50:player0y=50 player1x=20:player1y=20 player0: 011100 011000 ...
The lines above starting with "player" need to begin with a space or two.
-
The assembly looks right. p{0} would be the rightmost bit, and p{1} (ES1) is the next one over, so a mask of #2 is appropriate.
In a nutshell, the assembly code...
1. loads the byte with the ES1 bit into the A register.
2. keeps only the bit for ES1.
3. If the result is non-zero then a branch is taken to skip over the "jmp .JV2" code.
Functionally, that's the same as your basic code.
Want to post or PM the code?
-
Nothing jumps out at me.
Can you open up the resulting .asm file and post the assembly code that resulted from line "if Crash_Value=Land_on_Enemy then ES1=0: Enemy1X=0: Enemy1Y=0"?
-
Wow, that's really, really cool!
Good job!
-
OK, makes sense. I wasn't aware of that. I know that AA makes one-off carts. Can they handle games that use Superchip RAM? Even if it doesn't get sold in bulk, it would be pretty cool to have it on a cart.
The "melody board" option is capable of doing it, but $25 plus shipping (while reasonable for one-offs) makes it less appealing to use it to roll your own run.
If Al wants to carry it in the AA store then he'll have other terms for RT.
I wish there was an alternate source of melody boards. I have a WIP that isn't really appropriate for the AA store, but its 32k, which makes alternatives tough.
-
A reminder for all of us to regularly back up our game files to a USB flash drive or DVD or something.
Yep. I had a hard drive failure that killed some WIPs too.
After that I backup after each work session by sending it to my gmail account as an attachment.
-
Well done RT! I downloaded this in the morning to check it out, but I liked it so much I broke it out at lunch for a round or three.
I think the shooting multiplier is a great mechanic, and the other elements definitely keep you motivated to move around.
I agree with jrok that it could one or two more enemies that had more variety. Maybe a mutant frog that thinks the manatee is a potential mate.
-
Man, this thread is full of drama, just a good thing you guys don't have your fingers on the nuclear button
Is that button analog or digital?
-
4
-
-
A tune isn't required, but it might be cool to have some kind of sound effect. I'm thinking along the lines of how a lot of arcade games do for their attract mode.
It doesn't have to be overly in-yer-face - a single note or noise played a few times with decaying volume to simulate echo, or a low-volume phasing effect.
-
if player1y-player0y<30 then var6{1}=0 else var6{1}=1
I'm able to compile that line of code without an error, so I think there must be something else wrong with your program. What makes you think it's in that line? What does the error message say?
Michael
I think compiling it requires this build of bB.
-
Phosphor Blend, no matter the value, looks much better than what I see on the Atari.
Agreed. IMO turning off Phosphor Blend and using GL Vsync gives the closest approximation of a real Atari on a CRT, including color blending.
Stephen A has stated a bunch of times in the past that the Phosphor blend is there to enhance games with flicker, not to accurately simulate a TV.
@jrock: Definitely minimize the luma contrast between the flickered elements. But don't get too caught up on the absolute purity of the color of the guy's shirt and pants. When you flicker with a colored background color constancy kicks in and people perceive the colors as relatively pure even though they aren't in the absolute sense.
BTW, kick ass start!
-
The question is - is it still Atari 2600 game when you start adding extra RAM, bankswitching... For sure the only hardcore genuine game would be the one that fits the system specs from 1977 - meaning the real professional Atari 2600 coder wants to make a game that fits into 4k ROM 128 bytes RAM full stop.
Actually 2k (1977 standard)
Yup.
And the Real Professional Atari 2600 Coder wants to make a game using only techniques documented or known from 1977 too.
Its still a 2600 game when you add bankswitching and extra ram. Neither of these things is a panacea; you're still pushing everything through TIA and you're still squeezing code pieces into the jigsaw puzzle of your kernel.
IMO The Real 2600 Homebrewer uses bankswitching or sc ram when he wants; not as a cheat, but to deliver an experience that wouldn't have been possible without them.
-
The nibble code seems to work fine in other programs, so I'm thinking there's some other condition that must to be present to trigger the bug.
-
Thanks for the help. Like I said in the first post, something stupid like a goto that doesn't belong can cause no error and everything will seem to work fine, but add some more code later on and you'll get hair-pulling errors that don't seem to make any sense.
I've seen "hidden" errors that don't relate to the compile error, but I haven't seen what you're describing before, so please report it if you do find it.
Feel free to post or PM the source if you want help with the hunt for the needle.
-
Looking at it again, this is wrong in the assembly too: "LDA Ship_Up"
It should have been "LDA e" instead, since Ship_Up is e{0}.
Looking through the older bB source (batari hasn't released the newer source with DEF and other stuff in it, AFAIK), it seems that bit to bit assignments don't have any syntax checks for the stuff between the {} brackets.
So if you do something like "b{0}=a{ }" or "b{0}=a{" you get assembly like...
LDA a
AND #65536
(...)
...which looks just like yours.
Anyway, the upshot of this is I think DEF isn't feeding the bitwise assignment the right stuff.
Hopefully batari reads this and replies.
In the meantime, maybe you can reduce some of the less frequently used DEFs and use dims instead, like we used to before DEF.
eg. dim Debounce_Reset=h
... lots of code later...
if Debounce_Reset{1} then blah blah
[edit - tokumaru, I just saw your post above mine. You win.
] -
Glad to try and help.
I didn't realize that it was a bit being assigned to a bit. The assembly makes a lot more sense now, though obviously the "and #65536" is invalid.
For "Shot_U_Snapshot = Ship_Up" it should have been "and #1", since Ship_Up is e{0}.
Why its doing that isn't as clear. When I create a .bas with your DEFs and the "Shot_U_Snapshot = Ship_Up : Shot_D_Snapshot = Ship_Down" line it compiles fine.
-
...
Why factor that out?
Is there some purity you are reaching for, minimalist expression?
So, that's where it is for me Divariski. What's the end game here? Is this some kind of Zen journey, where the path taken is the reward, not the product? Is it like scratching a itch, when relieved, is a loss in some bizzare need to do the scratching itself, rather than resolve the itch?
...
I don't believe there is an end game, other than an attempt to inflate self image...
http://en.wikipedia.org/wiki/Superiority_complex#Definition_and_Potential_causes
...its the inferiority complex I'm pointing to in that entry, and I'm not trying to be unkind or glib. Its just the only explanation that makes sense to me at this point.
I'm done with the game. I had fun with everyone examining the broken logic and the desperate attempts at patchwork, but now it's getting a bit creepy.
-
4
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Digital Joysticks provide better control than Analog Joysticks
in Atari 8-Bit Computers
Posted
Your analogy was perfectly understood, but since your assertion that digital joysticks provide superior control without qualification was already disproven in post #18 and many after, your analogy serves no point, except to ironically underscore the fact that we are beings with analog brains and analog limbs.