Jump to content

RevEng

Members
  • Content Count

    6,767
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by RevEng

  1. Literally stunned right now, reading this news. Kurt was skilful to the point of being a legend, and more importantly he was a genuinely nice, helpful, ego-free guy. He will be missed.
  2. 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.
  3. 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"?
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. It's a good thing because it means people won't be motivated to turn out games that aren't desired. The market will speak, and punish them. It's a good thing because it might support a different class of classic game dev. Believe it or not, $300 isn't "major profit", and that's one-time. For one, the NFT cost $120 to mint. For another, selling this sort of NFT is a promise to keep the thing the NFT represents (as opposed to the NFT itself, which is on blockchain) available as long as a viable market exists. So I'll have domain and hosting costs for the foreseeable future. I take it you never accepted more than $30 in royaltees from Al?
  17. So why can't homebrew developers have a go at turning professional, too? (or "indy", if you prefer) If music and gaming in general can support different classes of participant, there's nothing stopping us. At some point none of those musicians or artists were professional, and they moved up the gradient from "hobby" to "professional". Currently we have things like Patreon and Steam to support the gradient ascent. I'm trying to cut out those middle-men.
  18. Yeah, I like the "first", but the likely outcome is you'll have a model of what not to do, when you're ready.
  19. I think we'll just have to agree to disagree here. I support efforts like TailChao's Rikki&Vikki game being sold via emulation on Steam. In the end it wasn't a path to profitability, but if it did work out, we would have gotten more amazing games for classic platforms like Rikki&Vikki. I'm trying to explore a similar (but different) model. Legitimate question - do you feel all music and art should be free too, without any monetary motivation?
  20. 1) If I sell it for $30, there is little motivation for a buyer to resell it vs sitting on it (either for speculation or they can't be bothered) which means no game distribution. There's one NFT. 2) If there's market liquidity, it's not $300 you're spending in the traditional sense. You recoup some-of (or more-than that) upon resale. (again, assuming market liquidity)
  21. Answer for NFTs in general: there's wide number of use cases beyond "this is a one-of a kind digital work (which anybody can copy+paste)". As Andrew said, NFTs are proof of some kind of ownership (a buyer should know what that specific ownership is, because it will differ from NFT to NFT) and have on-blockchain contracts built into them that can do interesting things. Unfortunately big buck "tulip mania" NFT sales have overtaken the news. Answer for my game NFT in particular: the buyer doesn't lose rights to using/selling the rom (and cart) after they sell the NFT on the open market - in fact, if there are future updates, they will have access to them long after they've sold the NFT. I don't think that's milking collectors. It does expose the game distribution to a perfect market, however, which has interesting features. People may speculate on the demand for the NFT. The price may go up for a desirable game, the price will likely go down for one that's not desirable. In the traditional distribution method, speculators will buy up limited runs of certain games, and sell them on ebay. My distribution method discourages that behaviour, and even sends a small portion of that speculation market back to the author. I have little doubt many people will still conclude I'm trying to milk gamers, collectors, and their mother-in-law, with my NFT. I can only say that my motive isn't participating in tulip mania here - if I wanted that I would have just allowed access to the rom when you hold the NFT. I'm positive that the future distribution of works from small artists will someday look like something like my experiment, and I wanted to participate in one of the first baby steps toward that, but honestly I'm probably a decade too early here for an number of reasons. I'm not expecting any AA buyer participation, and don't encourage it either - I strongly recommend that people should stay away from any crypto propositions they don't understand. (the exact same recommendation should go for any fiat currency propositions, too.) I was hesitant about creating an AA thread about the project (legit wasn't looking to encourage any AA buying participation) but if you or anyone else wants to go into more depth, or has more questions, I can go ahead and do that. Let me know.
  22. Yep, that's a good way for lower-ranges. It does get a little out of hand for comparisons, for larger ranges. Near powers-of-two aren't bad either. You just have to throw out results that don't match and go back to the pot. Depending on how close the range is to the power-of-two, you only wind up iterating on occasion. ; return 0-2 getval val=rand&3 ; val is 0-3 if val>2 then goto getval ; throw back the any 3 result Of course, it's not a good choice for large numbers that aren't near a power-of-two. We have a thread somewhere here that have combined power-of-two random routines that are quick, but not evenly distributed. Something like this... val=rand & 127 val=val+(rand & 31) ; return a value between 0-158 gives a probability curve that looks like this... ...which might be fine for some purposes, and beneficial for other purposes. (ignore the jagged line. the segments would be perfectly straight from a probability perspective)
  23. Yep, completely agreed - the thing is, it can be resold while maintaining rights to the keep rom, burn a cart, etc. so it's not the actual cost. It's a bit of an odd proposition, but I'm sure we'll get into the economics during the show, the difference between it and NFT rocks, etc. Should be an interesting discussion.
  24. Here's a trace of the last gasps of the program. The KIL command and yellow screen is 7800basic doing it's thing when BRK is unexpectedly encountered. Quick guess is it's an unmatched bankswitch gosub and return with thisbank. Comparing the addresses in the trace with the .list file will let you figure out which 7800basic statements lead up to it. plumb.trc
×
×
  • Create New...