Jump to content

orange808

Members
  • Posts

    399
  • Joined

  • Last visited

Posts posted by orange808

  1. 3 hours ago, negative1 said:

    none of those reviews, or footage explored the game fully.

     

    none of those players were experts at marble madness.

     

    not one of them complained or commented about the imbalance in gameplay.

     

    only now after people have scrutinized it, that we now about it.

     

    it's easy to complain after that fact.

     

    later

    -1

    To be perfectly honest, people were so damn busy begging for the rom, they didn't ever really stop to listen to anything anyone ever said about the game. The first thing a person always got (if you did weigh in on playing) was, "Where can I get a free romz downloadz?" "Do you have the romz?" 

     

    Did nobody ever talk about it at all.. or did the conversation always go toxic? Rom beggers didn't want to talk about the game at all. They wanted to bitch that they didn't have their free download yet. 

     

     

     

    • Like 1
    • Haha 1
  2. It's a relief to finally get past the Pink Panther and Marble Madness 2 rom begging and complaining. Everything will eventually find its way out into the romz.

     

    The funny thing is that MM2 has been available to play often (on site) for years. Many people have volunteered feedback on the mediocre gameplay. It's not a polished product. I hate the tower mechanic. Atari over engineered the game. It needed to be completely reworked. It sounds bad to recycle the original design with modified maps and updated assets, but that's precisely what this release was begging for.

     

    I enjoy the development documents and focus testing notes. I can't figure out if the joystick was a hail mary to save the game or if the devs really believed the trackball was an issue. The game (itself) is the problem, not the trackball. I still wonder if the devs knew they had gone too far with a bad design and they were trying to salvage it.

     

    It's hard to believe the devs actually believed people couldn't understand a trackball. The same general theoretical overall "sample group" (at significantly more advanced ages) managed to understand using a Wiimote. I also personally saw little kids playing the original Marble Madness on site cab (using the trackball) in it's heyday. The intuitive nature of the trackball was the hook. The connection between the marble and the trackball was a major part of Marble Madness's appeal.

     

    I assume the focus testing results were either misunderstood or massaged. MM2's problem is:  MM2. The inherently intuitive nature of mirroring a ball controller to the ball on the screen is obvious and understood--and that isn't hindsight. I knew that in 1990. I still have a hard time believing the trackball was ever really in question. If it was, well... ... game designers shouldn't recreate or use Atari's focus group methods.

     

     

     

     

     

    • Like 3
  3. 3 hours ago, Thomas Jentzsch said:

    Yes and no. CRTs were around 5ms (compared to 16ms for one frame at 60Hz), so there you are right. But we are trying to reproduce the perception effect on modern monitors. 

     

    BTW: This is a cool link which shows the perception "thing": 

    https://www.testufo.com/eyetracking#pattern=lines1&speed=0&foreground=ffffff&background=000000

    Oh yes, that is a great site. I'd argue that Rajon changed the world with BlurBusters.

     

    There was a brief period where younger gamers were completely unaware that they were staring a blurry mess of crap on their bad LCD monitors. Had to smile when a friend's son took a verbal swipe at my "clunky old heavy" CRTs. Equally funny, hearing an honest reaction the motion clarity of NES games on a proper CRT. The kids didn't even know unless they met someone to show them. Fortunately, Rajon found better ways to get the message out and we have some BFI options these days. ?

     

    I also have a good friend that mocked me for buying a big heavy expensive CRT monitor after he got a new LCD.  Funny story, he has since retracted his comment. I still have the CRT and maintain that monitor. His crappy blurry LCD is sitting at the bottom of a trash pile at the dump. I actually chose my monitor after seeing his new monitor in action and lying to him about liking it. It was an abomination.

     

    As for the effect of a nice bright light on my eye:  I know it's obvious, but the easiest method to experience retinal persistence is looking at a light for an instant and quickly closing your eyes. ?

     

     

  4. The red color doesn't make any difference at all. 

     

    I posted a video with multiple displays and comparisons if you need to see it in action.  ? It's a perception thing.

     

    The entire screen goes completely blank (and completely gone) before each new frame is scanned out. There is no persistence on screen at all. That's why CRTs have some great motion resolution.

     

    There is persistence on screen with modern "sample and hold" displays. However, your eyes are holding the glow of a CRT because of the brightness. 

     

    I remember the horrors of legacy LCD screens. This isn't really image persistence on screen.  ?

  5. Commodore 64 owners didn't have very much buyer's remorse. This ridiculous conversation is as old as widely adopted mass market subscription internet access itself--and it's always fueled by some crazy (and wrong) logic that the market was wrong--except it wasn't. Also, I had friends on my block with an Atari 5200 and zero working controllers (a big sexy doorstop) just months after getting the system. You can't say "except for the controllers".

     

    Other than that, how was the play Mrs. Lincoln?

    • Like 2
  6. 22 minutes ago, rsiddall said:

    Would it be fair to say if you're comfortable in the standard kernel, making the transition to DPC+ wouldn't/shouldn't be as intimidating as one might think?

     

    That was the point I was trying to make.

    The development experience is going to be similar between all the flavors of bB kernels. Each particular kernel has unique trade-offs, so switching between them will always require a little adjustment, but I can't see why any one kernel would be significantly more intimidating than another.

     

     

    • Like 1
  7. No. bB DPC+ is not really an extension of the standard kernel. The standard kernel isn't limited because it's primitive or it was poorly written. bB DPC+ isn't an optimization of the standard kernel; it does more because Harmony cart hardware adds additional processing power. DPC+ also leverages a different HMOVE technique.

     

    It's only an extension in spirit. Both kernels try to provide a general purpose display for making games.

     

    bB DPC+ updates both the state and color of:  the players, background, and most of the playfield (playfield 0 is blank) every single scanline. The missiles are every other scanline. I don't remember if the ball is every scanline; I think it's every other scanline. Additionally, the DPC+ kernel includes "built in" flicker handling for player 1 and repositions player 1 after six scanlines. Pretty good.

     

    bB DPC+ uses a technique called cycle 73/74 HMOVE to reposition player 1 sprites. The standard kernel hits HMOVE in the standard fashion. Otherwise, it would have required eight blank scanlines or a symmetrical playfield for bB DPC+ to do its "virtual sprite" work. The 73/74 HMOVES also prevent the signature small horizontal lines that manifest inside playfield 0 on the left side of the screen when you hit HMOVE during the kernel, but playfield 0 is blank (doesn't matter much). You give up the theoretical ability to draw slanted vertical lines with the missiles or ball and compatibility with the 2600 Jr to reduce flicker.

    • Like 2
  8. You are updating the variable associated with the horizontal position after the kernel has positioned the VCS objects. Just for clarity, this is not a bug; it's because you changed the value of the variable after the position of the VCS objects were set. Essentially, you really are changing the position in the next frame.

     

    "Getting around it" would require dropping to assembler (and probably changes to the batari Basic code as well). That will take you out into the weeds.

     

    TLDR:  You have to work around this and make sure you have updated the "x " positions for your VCS objects before VBLANK. There's no reasonable way to change it.

  9. 4 hours ago, Clint Thompson said:

    Sounds about right, though I'm not sure how much better of a game Kasumi Ninja would have turned out regardless sadly. Always felt it looked good but gameplay was bad.
     

    That's okay. I'm not expecting to find a better game. At this point, the stories behind the games are as interesting (and sometimes more) than the games themselves. I'd like to hear and see more about Kasumi Ninja.

     

    Slightly off topic, but I used to particularly enjoy the postmortem features over at Gamasutra. Those gave a lot of good insights into how the creative process. Although, I admit that an unfinished prototype wouldn't tell much story, I'd still love to see and hear some of the team's ideas that didn't make it into the cart.

    • Like 2
  10. 1 hour ago, Al_Nafuur said:

    ?

    For finding diffs in two or more ROMs it doesn't matter if it is 6502 or ARM code (or data or free space, or whatever).

     

    however it would be possible to compute a checksum of the differences (with the ARM or the 6502) and the ROM would simply refuse to work if the checksum doesn't match a certain condition. But this would be much more effort than a simple watermarking..

     

    Could probably hide the ability to access the computed value. Might not ever show it to the user at all. There's also some neat tricks you could do with cryptography that wouldn't require too much effort. Don't have to actually do the computations in the game. A pair of values "in the code" that are related using cryptography would be extremely unlikely to occur due to entropy.

     

    It's just a watermark. DRM that disables software is never a particularly good idea, in my opinion. Risky Rick tried to tie DRM to hardware and it ended up affecting their paying customers.

  11. In theory, two roms have to leak to reliably find and remove a watermark. That's particularly true if you throw a little something extra into the code. Could be as simple as slightly changing an asset.

     

    Probably more secure if each tester doesn't see fresh randomized information and/or individualized asset modifications (wrong color, pixel, sound) with each new build, so there's no baseline for comparison between them.

     

    Wouldn't want to juggle all of that for more than three or four people, though.

    • Like 1
  12. It's a commitment. And, you're not just playing/experiencing the game once for fun and offering advice. It's actually a little bit of work.

     

    You can have fun, but testers should probably find pleasure in more than just consuming a video game for pure entertainment. Not that general feedback on the experience is without value (opinions do matter), but there's more than just playing the game. You are also hunting bugs.

     

    You're going to intentionally play it wrong and try to break it. In fact, you want to break it. So, instead of that natural experience of playing by the rules to win, you need to invent "what if" scenerios and try them--understanding that you will have to do it a few times and you will lose the game. So, you're not really playing to win; you're playing to find bugs. And, you are trying to brainstorm batcrap crazy things to do that will break the game.

     

    When you do spot a bug, you will probably spend some time trying to reproduce it. You may even spend half an hour trying to lose and doing the same (monotonous) things over and over again. And, of course, there's the time you'll spend trying to articulate what you found. The dev needs a process to reproduce the issue.

     

    It's not the same thing as downloading a demo version of a rom. That's why I (personally) don't have time to help out right now.  :-(  I do hope I can find someone that will have time if I ever get this thing far enough along to need testers.

     

     

    • Like 2
  13. Platforms can be a big deal. I saw there were some upset people in the Zarkstars thread. Of course, the biggest thing is keeping prototypes off archive.org. Really need testers that will agree to delete the roms. "Preservation" is the developer's business.

    • Like 1
  14. I suspect large retailers were able to negotiate lower prices for carts. Atari was probably willing to go down a bit--and I bet they did.

     

    Sears, in particular, should have had significant leverage and negotiating power with Atari--and I imagine their relationship benefitted Sears handsomely. I also don't know how Atari accounted for the risk of the remarkable guarantees they provided to retailers. So, I think the Wikipedia gross profit estimate sounds too high--and we (also) don't know how they valued their risk. Atari had to make some big sacrifices to get their products into stores.

     

    We also don't know about internal conversations. I know Atari management wasn't particularly good at bridging the business/accounting/advert team with the creative team, but they still communicated. If devs had been asked about Donkey Kong, the responses may not have been encouraging. If someone at Atari had been thinking about making a port and already started something promising, it may have gone down differently.

     

     

  15. If a video game stops being entertaining and becomes a chore, it no longer serves its purpose. Games are fun, by definition. Where and when something becomes "unfun" depends on the individual. That's hard to get right. ? Don't worry about it. 

     

    It's not just old games. There's no shortage of new games that are intentionally obtuse. It's what you do when you're a dev in your twenties. ?"I have tested this level five hundred times and I can finish it easy, so anyone that can't obviously just sucks at games."

     

    Live and learn. ¯\_(ツ)_/¯  It turns out that identifying "real gamers" and entertaining people with a fun game are not always the same thing.

     

    • Like 4
  16. In addition to the 5200's limited install base, Coleco's investment and complete commitment to their Cabbage Patch brand was gaining steam inside the company throughout 1983.

     

    Also, the Commodore 64 was creating major headaches and "quietly" (but not really quietly) eating up video game dollars. To this day, C64 spending is conveniently placed in the "computer" category, because it helps make the "video game crash" look worse--and everyone loves a great story. Truth be damned. Like any good fish story, the big fish you landed must become more collosal with each telling.  :-)

     

    The C64 managed to stay very close to the Atari 5200 on initial price tag throughout the 5200's short life. That really (really) hurt. The details of total investment didn't matter much. People saw the bold print and made their decisions; Commodore did get us to spend more, but nobody really thought about it. We also told our parents we could learn and get good grades with a computer. Couldn't make up that lie about a game console. We knew what we wanted: games.

     

    The market did its thing.

     

    As always, the internets are absolutely packed with fanbois making up crazy conspiracy theories on why Atari products have failed. The internet has been circulating the same tired lines since Compuserve--and I've been reading the same recycled nonsense for decades. It's still not true, of course, but I know I can't stop it. So, flame away. I know you will.  :-)

     

    Here's the inconvenient truth: Atari products didn't fail because of conspiracies. They failed because Atari made huge mistakes of many different kinds--and other companies outperformed Atari's poor management. For the perceived price, the C64 was the best buy in gaming during the 5200's life and they were essentially head-to-head on pricing.

     

    Word of mouth mattered as well. I had friends down the street that had a 5200. After a few months, we couldn't play it; all their joysticks were busted. I knew what the 5200 was by 1983 (actually before) and everyone at school knew it. We were already making jokes about the joysticks in grade school. The mold was set and the verdict was in. We can't look it up on the internet and "prove it", so the conspiracy theories will continue. Flame on.

     

    Flame away. Anyhow, the games didn't hit the 5200 because the machine was a failure and Coleco was hawking Cabbage Patch dolls.

     

     

     

    • Like 6
  17. I really liked this piece. It's fair and honest:

    https://www.videogameschronicle.com/review/playdate-review/

     

    Some of the other reviews feel very very enthusiastic. It's almost as if a lot of people loved it before they ever played it. That's great, but is that the right state of mind for writing a "review"?  Hard to say. I could be wrong. Maybe I am.

     

    The $180 price proposition will (and really should) be polarizing right now. I understand the price is justified, but I am still on the fence. Guess it doesn't matter, because the machine is unavailable for the immediate future. ?

     

    Would be nice if they eventually implemented a curated store and let more indies in. I do love the ability to sideload as a built in option. Hopefully, that will deliver more than just emulators...

     

     

    • Like 2
  18. TIA has five freely positionable objects and that's all there is.

     

    Even with bus stuffing and ARM assist, it would be very challenging to draw more than two freely positionable individual truly multicolor sprites on a scanline--meaning true sprites that can be freely positioned on any given scanline, with their own individual colors (for each line and a not shared color with anything else), and able to manifest in any possible pattern:  that can represented by a byte as a binary pattern of eight color clocks.

×
×
  • Create New...