Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


RevEng last won the day on September 5 2020

RevEng had the most liked content!

Community Reputation

6,382 Excellent

About RevEng

  • Rank
    ​​ 👾 Space Cowboy 👾 ​

Profile Information

  • Gender
  • Location
    ​ 🇨🇦 

Recent Profile Visitors

46,492 profile views
  1. By random graphics, I'm assuming you're talking about the cockpit display here. It's best practice to rough-in everything you need to display, to ensure you won't actually blow the dma budget. Actually making the displays do something, even random or cycling, prior to a fleshed out game is a good way to fire-up people's imaginations for show-and-tell. I see a whole lot of "what to do" in your critique choice here. On your broader point about it not being finished, it's a proto. We all know what that means. As Trebor already highlighted, the only lesson in "what not to do" is not have Jack Tramiel calling the shots on your project, if it requires anything more than base hardware.
  2. It's not playable beyond steering the ship, but it works very well to show off the tech proof-of-concept. Spectacularly well, in my estimation. What lesson do you think it can teach developers, as far as "what not to do"?
  3. Thanks for the contribution - It's been merged into master. There's a few other issues I'm working on, after which I'll put out a binary release.
  4. One more wrinkle worth mentioning... RoF uses a half-vertical resolution bitmap (i.e. squarish 160 mode pixels) which cuts down on number of pixels it needs to thrown on the screen. The 7800 doesn't have such a mode, but the on-cart ram has an address line pulled down permanently, so that each odd graphics memory page maps to the prior even page. (aka "mirror ram") Thanks to the way 7800 graphics blocks are laid out, this turns the higher res mode into half-resolution.
  5. What's the point of "true hardware sprites" in the NES if they're gimped compared to the 7800? (which isn't exactly soft-sprite either) The 7800 can push over a hundred sprites per frame with no flicker in sight, while the NES tops out at 64 per screen. Each 7800 sprite width can be up to 32 bytes wide, instead of the NES fixed width of 8 pixels wide. Any game object wider than 8 pixels on the NES has to use multiple sprites, which is problematic due to the max of 8 sprites per scanline. The truth of the matter is, the NES is fantastic with tiles, and weak with sprites. The 7800 is fantastic with sprites, and weak with tiles. A clever programmer can overcome the NES limits by abusing tiles, and a clever programmer can overcome the 7800 limits by abusing sprites.
  6. Oops. I misunderstood the initial report, and took it as sfx data in the if...then. Since the list output was interrupted, I didn't get clued in. Thanks for clarifying. Back to the drawing board.
  7. Looking at this, it appears that a multi-line statement with end doesn't play nice when it's part of an if...then. It trips up the preprocessor, which prematurely ends the program. I think this one is just going to be a documented limitation for now. Multi-line statements in a single-line if...then is going to be clumsy anyway, from a syntax perspective. Maybe at some point I'll take a whack at adding a blockif statement.
  8. Ok, can you send me the list file from a broken compile in PM? That might help me track down why dasm didn't report choking on the assembly, despite the fact it only created a malformed 8k rom.
  9. The playsfx is one of those inflated statements that cause the if...then logic to trigger an out of range branch. Are there messages elsewhere saying the source wasn't resolvable? This particular error you've flagged is actually issued by 7800sign, which gets run post-compilation. It's noting the rom is malformed.
  10. Just a quick update on everybody's favourite and completely uncontroversial topic, the Ethereum 2600 NFT... heading into the weekend I lowered the minimum bid to 0.01 ETH (about $39) because I was worried about being off the price curve entirely. It was a bit of a risk for a couple reasons. First reason being the lowered price reduces impetus to resell, which could end redistribution. Second reason being the fact that I was trying to walk the line between collectable and game with this project, and I didn't have any idea if I was looking at a regular demand curve or Veblen demand curve. For the latter, lowering the price reduces demand. The auction ended this afternoon without any offers, and then a few seconds later I was sent an offer of 0.18 ETH. I'll be accepting it later tonight. (just waiting for ETH gas fees to come down a bit.) This update isn't in lieu of that post-mortem I said I'd do; I'm still planning to get that out this coming week, and with some luck there might even be some resale info in it too.
  11. I agree the difference in reactions was instructive. This is totally one of the factors in my previous statement that I am "probably a decade too early here." A good chunk of the general public's perception is that crypto is all a ponzi scheme, and NFTs exist solely for money laundering. If you break down the public by age, this absolute negativity is more common in older segments, which doesn't help my case either. However things play out, some time next week I intend to put together a post-mortem of sorts, going over decisions that were made, what factors helped or hurt, etc.
  12. Thanks Karl, I appreciate that. The fact that a lot of developers watch the show is why I reached out to James. I figured that karma balance would allow for the idea to be aired and discussed reasonably. I certainly knew the topic would be controversial. The ideal outcome of the project to me would be initial buy interest from people who are already crypto-savvy *and* interested in classic games (and likely get a kick out of the combined novelty) which would prove out the distribution concept, and establish that there's market liquidity. (i.e. there are sufficient interested buyers for the holder of the NFT to resell it.) Crypto-savvy folks are more familiar with the risk of insufficient liquidity (or at least should be) and other issues around crypto, so I don't have to worry about their decisions being ill-informed. If there are people on AA that hold and use Ethereum (the cryptocurrency) I'm not telling for them to stay away. I just don't want to try to be the driving force behind anybody purchasing a speculative+volatile asset (crypto) for the first time, for the sake of playing a classic game, nor am I pretending that my NFT has proven liquidity. If that dooms the project, so be it. This is very much an experiment in hill climbing, and honestly, success is unlikely. I consider Rikki&Vikki part of the same hill-climbing experiment. If my climb works, others can follow me up a similar path. If it fails, then the path can be marked as failed, and the next attempt can be a little better educated as to what doesn't work.
  13. Nobody is trying to kill that. Clearly you'll still be doing it, and I don't imagine you'll be alone. [edit] there will also be a large percentage of players that insist on free games, so you'll always have an audience too. These things can coexist.
  14. Yes, I accept an indy dev working on classic platforms will have different motivations. Yes, it won't be art for art's sake, but rather a reflection of what the artist thinks the customer wants. I don't see that as a bad thing. It doesn't mean that hobby coders will disappear, any more than hobby musicians have disappeared. If money in our hobby is a bad thing, then the consistent belief is that money in music and art is a compromise. If you only listen to hobby musicians, and only partake in hobby art, then I applaud you. Otherwise it's an inconsistency.
  • Create New...