Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by rje

  1. I wrote a quick thing that shows that when CS%=0, it never takes a branch, assigned or no. Is that what you're seeing? You probably want something interesting. Otherwise you'd force CS% into the range you expect with something like if CS%=0 then CS%=1 Two ways to store game state are (1) a SEQ file, which requires an SD image mounted; (2) POKEing it into your favorite RAM bank (Ha!). A third, uncool, way to store game state would be to VPOKE it into VERA RAM. I've used video RAM before to store game data, like a poor man's steganography. I don't recommend it unless you have a reason to use it. Bank 1 might be the easiest way to preserve state. One byte for CS%... and 8191 more bytes for more stateful data. Then use Bank 2 and up for other data... rem get ready to load a different BASIC program. rem because this blows away low RAM, we gotta rem save state in high RAM. poke $9f61,1 :rem switch to bank 1 poke $a000, cs% and 255 :rem store the low byte ...load another BASIC file... ...at the beginning of the just-loaded BASIC file... poke $9f61,1 :rem switch to bank 1 cs% = peek($a000) :rem fetch state on cs% goto ....
  2. Elegant and very clear! Thank you. Yes - I store the upperleft, the width, and height. You've made me realize that some of my windows are very specific to the data being rendered: the status line at the top is ALWAYS going to be an alarm bar with the same component groups listed. While the actual component groups may change ship by ship, the nature and form of the data will always be the same. So there could be coupling of data with presentation. I'm agreeing with the tendency to move to use GET instead of INPUT. I was kind of thinking that I need to swap out the middle windows based on the game's current mode/state. User input changes that state; windows reorganize accordingly.
  3. Inverting the text is a GREAT way to show selection, old school and effective. I'll keep that in mind, as well. By the way, the first POKE sets the view to Bank 1. It doesn't affect the LOAD... but it's needed for all the PEEKing. And yeah, if you can map an ID directly to a memory address (or use known indexes... item 5 is always at offset 5 x 64 or etc), then that works. If you're BORED you can pre-parse records with varying lengths, and store the addresses into a BASIC array. I prefer not to do that if possible! (P.S. "sorting" would probably be exactly that: building a BASIC array of addresses based on some sort criterion).
  4. Yes, you will save space, at the mental load of remembering those variables. And might render quicker -- save the entire first three lines of the message box into one variable, and the lower three into another var. Regardless, "print a message" could be a subroutine that expects the message to be in a string like ms$. The subroutine nestles said content into a nice message box. Use len(ms$)/2 to pad it on either side with spaces... etc. Of course! I hope the example helps. I've started encoding as much data as possible into binary files for storage in high RAM. I've even got a couple of trade tables leveraged that way. Anything to help organize things better. (And I see you've found some errors in my data. I will have to fix those!) I've also shoved the star charts into binary files for loading into high RAM. THAT took up on the order of 20K of low RAM for one measly subsector... totally unacceptable. Now I've got a question for you. Your screen presentation has several views on it. I was wondering if you do what I've been doing -- that is, brute-forcing the data to specific places on the screen, all at once -- or if you've figured out a more elegant, flexible, maintainable way to present data? Because I'm kind of stuck on the data view. I've got this pretty set of "portal"-like areas, into which I very very carefully try to render data, and it's going to drive me mad having to keep track of cursor positions. I need to separate the concerns, so that I have loose coupling but high cohesion.
  5. Remember that wartime caution against stowing your 386sx during the Nazi occupation of Europe: loose feet sink ships. Or something like that...
  6. Thanks for the "N" bit... a holdover to the Bad Olde Days! Because it's a clarification ("SEQ" is more obvious than "S") rather than a confusion (the "N" prefix is a confusion), I'd recommend always keeping this bit of syntactic sugar... especially when you've got the extra two bytes to spend.
  7. Ah, my transpiler is only a line scanner, kind of a macro expander only with a little bit of state added in.
  8. Brilliant minds think alike... I've been using my own, primitive "transpiler", which lets me use labels, long var names, multiple files, and eschew line numbers.
  9. As Strider says, I lack the time and space. I donated my C64 and disk drive 15 years ago to a co-worker who was an enthusiastic young techie. Then I sold my C64 game collection 12 years ago. Finally 10 years ago a very kind and helpful retro BBS guy digitized my three remaining 1541 diskettes for me. Those are all I have left, but they represent a significant portion of the coding I did back in the 80s, so I really haven't lost all that much. ...But I have room for an X16.
  10. Right. MEMTOP doubles as a READ MEMTOP and SET MEMTOP based on CC. MEMBOT is similar...
  11. Won't stop me from forcing the thing on edge. But, yes, it might serve as a nice platform for a monitor?
  12. Okay those are GREAT ideas. I really like the "Comms Terminal" bit. Injects a little old-skool mail kiosk goodness in there. Very nice. Agreed that the program should just import messages without fuss. I suspect this means it doesn't care if the message happens to be formatted "WRONG" as well -- hey data gets corrupted during interstellar travel. Keys are fine. I had thought about that, but I think I don't care for security. Like, AT ALL. So one problem avoided. I especially like the transience of the messages -- the game reads MAILBAG.IN's contents, and deletes the file. That's nice. In fact, that could potentially open up the desire to *curate* messages outside of the game. Some people like to scratch that itch. No problem. I just realized that this could be a way to partially save or transfer your game state... or at least the parts you want. I'll have to think about that too. And yeah, the cheating hole is there. So I'll just make sure it adds to the entertainment value of the game, instead of breaking it. Don't know how, yet, but I will. Some relatively innocuous messages would be * posting a welcome to this particular system * posting survey data about this system - this is nice in that it gives other players a leg up on a difficult data gathering task * posting standard freight to be carried out of the system - not sure about this one! It just occurred to me that the game itself can generate xboat mail. For instance, if a player is attacked by corsairs in a particular system, a news bulletin is automatically added to MAILBAG.OUT. This is also a way to propagate leaderboard stats. Since the mailbag can be hacked, I suppose that means that the player gets a line-item veto when inspecting incoming mail.
  13. In order to do this, you need to boot with an SD image. For example ~/commanderx16/x16emu_mac-r38/x16emu -sdcard ~/git/x16-a1-sd.img Now you can get things done. Here's a BASIC program that creates a new SEQ file. You'll probably want to write several separate pieces of data. The comma will separate data for you in a way that INPUT# knows how to read back in. 100 OPEN 2,8,2,"0:MY-NEW-FILE,SEQ,W" 105 CO$ = "," 110 PRINT#2, "ROB"; CO$; "10"; CO$; "2020"; CO$; "TEXAS" 120 CLOSE 2 The CO$ inserts actual commas into the SEQ file, so we can read them back in individually. Otherwise INPUT# would treat the thing as one long line. To read the SEQ file: 100 OPEN 2,8,2,"0:MY-NEW-FILE,SEQ,R" 110 INPUT#2, N$, M, YR, S$ 120 CLOSE 2
  14. I am brainstorming about a SOCIAL aspect to my Space Trader game: the ability to send "Express Boat Mail" to other players in other instances of the game. This is not a networked game. This is not a networked machine. So, any data exchange is going to be "sneakernet": sending PETSCII-encoded data, or copying files, back and forth. Maybe posting it to FB for anyone to pick up. In other words, the default mode is BROADCAST mode. It's interesting because social interaction is * fun or interesting * a way to gain benefits in a game * a truly random element of games It's limited because * it's hackable * it's low bandwidth, so to speak Consider that the limitations can actually be FEATURES. Hacking is encouraged. Successful communication might be difficult. The rewards have to be commensurate with social success -- how do you measure THAT? Answer: you can't really. But ... maybe some things can be encouraged without breaking the game. For instance. Consider that just the act of SENDING and RECEIVING an xboat message is in itself worthy of a reward. In that case, the content is less important than the effort made to create the envelope and transfer the files (in and out). It doesn't even require a REAL recipient... but it WORKS with a real recipient, and the messages are bound to be better off that way. I suspect the messages themselves will not be free-form. But I suggest that that could spike creativity. Thoughts?
  15. I've got nine. --- 8 bit --- M.U.L.E. 7 Cities of Gold Below the Root Bruce Lee Earth Orbit Stations (or, perhaps, Project Space Station) Pirates! Ultima IV --- 16 bit --- Space Hulk Doom
  16. https://www.facebook.com/robert.eaglestone.12 (There are 12 people on Facebook named Robert Eaglestone? Ridiculous...) https://github.com/bobbyjim
  17. Back to important things, i.e. RETROTREK (hey, I like all caps instead of partial caps... but that's just me). For your edification, here is code I wrote that reads data loaded into RAM Bank 1. I LIKE having data in the RAM banks because it can be packed in very efficiently, as opposed to BASIC floating point numbers. I dislike it because of the PEEKing I have to do, but I can work with that. Anyway, here's the BASIC code, and the binary file it loads and reads from. MAYBE this could help you with a plan of attack. ALLSHIPS.BIN shipbrowser.bas
  18. Thanks for that, Star. Especially Yes, this info is not worth storing! In this case it's worth a (short) wait time to render. And I've squeezed it down to half its original speed by tossing unnecessary extra steps. If I can shoehorn two lines of my BASIC into assembly I might speed it up by half again.
  19. I saw the "process" video, and saw that Computer Reset were helping him open those boxes. At that point, I realized "this is not valuable equipment". If it were, David would be using tweezers. I've seen how he tiptoes around Apple, Atari, and Commodore hardware.
  20. Here's a little more info. I can generate low-res maps on the X16 using a short BASIC program, and upwards of 1 minute each. They're interesting enough to consider. Example attached.
  21. Is it FEASIBLE to draw a full or partial "world disc" with a low-res map projected onto it? I suppose there are several ways to render a low-res map. My preference is to use color PETSCII to fill in a quarter- to half-"circle" on the lower edge of the screen. But, maybe you know a better way? ** I could just stick with a "recangular" map, for that matter. This discussion, though, is about showing a world disc. Example:
  22. I'd actually been wondering if the RAM banks could be abstractly treated as a device, with secondary numbers 0-255 representing bank numbers, thereby allowing transfer via INPUT# and PRINT#... yeah it's clunky. Devices 8-15 are all "disk drives" and 16-30 are "unknown". They're assumed to be on the serial port, but MUST they be? Suppose device 16 represents the RAM banks and device 17 represents the ROM banks. 1 OPEN 1,16,2,"0:DUMMY STRING,S,R". :rem read from device 16 (RAM Bank) #2 (Bank 2). Ugly!! 2 INPUT#1, A$, B, C$, D%, E$, F$ 3 CLOSE 1 It treats each bank as a SEQ file, kinda. Yeah it's ugly. Supa-ugly. And there are questions in my mind about how to issue commands. But... it might could let us drag typed data in and out of RAM banks.
  • Create New...

Important Information

Please review our Terms of Use