Jump to content

RevEng

Members
  • Content Count

    7,027
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by RevEng

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. Yeah, I like the "first", but the likely outcome is you'll have a model of what not to do, when you're ready.
  8. 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?
  9. 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)
  10. 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.
  11. 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)
  12. 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.
  13. 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
  14. So flipping beautiful, and that title screen is just crazy cool! Great job! I really like the animation on the background characters, but I think it gets a bit distracting once the game starts... almost over-stimulating. Maybe it could be slowed down a bit at that point? If the change in speed looks jarring, then maybe it could be accelerated/decelerated over a second or two.
  15. Awesome work-around. I have an idea at what's at the heart of this, but it's not easily solved. Basically the 8-bit values can underflow near or past the 0 coordinate edges. To work around it, I add an offset, but that can only go so far before you introduce the opposite problem at the max-coordinate screen edges. So Y box checks are reliable up to heights of (256-192)/2, or 32. X box checks are reliable up to widths of (256-160)/2, or 48. Beyond that, things get unreliable at the screen edges. This could be fixed by using 16-bit math, but that would cripple the performance. I do need to document these limitations better. Really this all dawned on me some time after boxcollision was written.
  16. No, not really normal. I haven't seen one die like that before. Usually it's just typical wear and tear type stuff. No directions is a bit odd, since up and down should work no matter what the select line sees. I'm trying to imagine what in the console could cause such varying symptoms between your two different genesis controllers. Maybe a marginal riot, or possibly the power supply isn't sufficient. Dunno.
  17. I use a generic 6 button, but they should all be more or less the same. The protocol to select the additional buttons on a 6-button controller hasn't been implemented in any 2600 games. The up and down directions aren't usable when the select line (pin 7, which is +5v on the 2600) is low. Are you using a joystick extension cable? Also, do paddle controllers still work in your console? If it's not an extension or console issue, then yeah, the mux chip in your genesis controller has probably died or the select line has somehow been broken.
  18. Yeah, highly likely you'll break your box if you try to upgrade glibc in isolation. Pretty much everything links to it. If one is determined to take this approach, then doing an upgrade of your entire OS using it's documented process would be the best way. But what you did - using your dist's stella and pointing ADS at it - is by far the easiest way to solve the problem. Great job!
  19. It's sorta known. (no need for apologies!) There's a few statements that eat a lot of rom, and as such cause branch-errors in the if...then logic. Resolving it requires a bit of re-write, and probably will grow the usage of if...then by a few bytes for each one, so I've been putting it off. For now, you can work-around by putting the rom-hungry statement on it's own line and using if...then to conditionally jump past the statement. As for the reason why plotsprite triggers the issue with a variable pallete failing but a constant one working... variable palletes use a bit more rom. plotsprite appears to be on the cusp of the if...then hungry-statement issue.
  20. I have a hacked version of a7800 that subtracts the dma cycles used from the total in each frame. When the action is at a suitable point I just exit and check the values printed out on the console. I'll share it, or something like it in the future, but it's very rough around the edges right now.
  21. The answer is "it depends on how much you're making Maria do". But here's some figures of non-DMA cycles per game frame, for some common games. This is in the midst of action, with a moderate number of game objects moving around. Alien Brigade 13163 Bentley Bear 12024 Choplifter 19660 Commando 16996 DigDug 20401 Food Fight 23198 Froggie 9052 Ms Pac 14871 Popeye 11506 Robotron 26260 Sirius 14971 T:ME Salvo 16970 Bear in mind that a good chunk of that will be updating display lists ("plotting" in 7800basic) so you don't have all of that time available, unless your game isn't plotting objects. But at least it should give you a ballpark idea.
  22. It can go anywhere - inline with your main loop, or within a sub that gets called from the main loop. The main consideration is that it needs to be part of your control handling code, since it allows/denies player movement in a given direction. As such you'd usually run it once per frame.
  23. Nerds often refer to the period symbol as "dot", when it's not being used at the end of a sentence. That would have helped with the search. A label that begins with a dot is limited in scope. i.e. if you use a particular dot label somewhere in a dasm subroutine, you can use the same dot label elsewhere for some other purpose, without a name clash. The reason for the dot label in this particular case is to make it possible to "gosub unrand" directly from bB source code. bB prepends a dot to all of it's labels, which means the basic code "gosub unrand" becomes the assembly code "jsr .unrand". A natural follow-up question might be "why does bB internally add a dot to each label?" The reason bB does that is to support line numbers as labels. Dasm doesn't support symbols that are just numbers, or even those that begin with numbers. So adding the dot to each label was batari's way to turn the line numbers into a label that dasm would accept. (bB doesn't actually use dasm subroutines at all, as far as I recall) The colon is just an optional dasm syntax for labels. Some people use it to make labels more obvious in their assembly source, or because they previously used an assembler that required the colon for labels. I typically don't use it, but I did for some reason here. (and inconsistently too, since .unrand doesn't have one)
×
×
  • Create New...