Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by rje

  1. I updated it yet more, and it's reeeeeeally close to done. I think. 1. There is one thing that is bothering me: the sound. I'm using Dusan's interrupt-driven sound routines. I'm not fully aware of the proper way to handle the PSG. As a result, if I don't include proper timers in my BASIC code, a SYS to call the sound routine might be made too soon to the previous one, with bad results -- the video goes a little nuts because the previous call is still working. Suggestions welcome. Maybe I should remove the interrupt logic. 2. ALSO, I think I want to write a little PSG goodness of my own, to play a little fanfare when you find the Amulet of Yendor, and of course when you die. I used the SID with BASIC... uh, 35 years ago... so... 3. ALSO, the "User Experience" suffers from the timers... However, the UX might just generally suffer from some bad decisions. And it has a downright ugly "game over" screen. Advice there would also be welcome. 4. Game balance. The game is highly susceptible to random chance. That's INTENTIONAL. But, the game balance is probably skewed. Although the last several times I played, I found it challenging enough so that I was never dominating the game, I think. Again, suggestions welcome. 5. Features. It is feature-poor on purpose. I omit potions, rings, magic effects, ranged weapons, etc. I omit the inventory. I don't have complex relationships between weapons, armor, and monsters. I think this is OK. Your suggestions are welcome.
  2. rje

    WASD Keyboard

    Alas, I got no dampeners. Or, perhaps, "we don't need no steenking dampeners!"
  3. I've updated Rogue Forest. The source is in a line-less BASIC 2.0, split among several files and with pseudo long variables. I need just a bit of "flash" and I need to tune the game balance; then it will be 1.0. https://github.com/bobbyjim/x16-rogue-forest
  4. You sound like you might fit into the core demographic for this sort of machine: "I want 8-bit hardware without the vintage tax of maintenance and breakdowns." Welcome!
  5. We will see... could be useful.
  6. No doubt you've heard about this. This makes me want to write a space sim for the X16. I feel that the myriad logistical challenges could create a great risk-reward balance.
  7. Dusan, I wanted to thank you for your web pages -- the tutorials are really well written.
  8. Heh. I guess we will see. I tell ya, a pile of random numbers in video RAM would be interesting. I'm not betting on it though.
  9. That's a good point, and I was wondering if a real FGPA will simply have zeros or a constant-fill in RAM ($DE $AD $DE $AD $DE $AD...). Randomization is never free, and never random.
  10. PETSCII Robots reminded me, yet again, of how nice and clear the PET's graphic characters looked. And... well it made me want a hybrid character ROM for the X16: one with the C64's letter font, but the PET's graphics. Is it wrong to want that?
  11. Welcome Wyrd. You're in good company, I think. We have some similarities. I'm in Dallas, full stack, retro leanings but no collection. Your "1999 Dream Machine" reminds me of the stuff LGR does on his channel. I agree that the PET is totally an awesome look. A PET shell with an X16 inside would be the bee's knees.
  12. That would be interesting indeed if VERA were to become available for other Commodore computers.
  13. In my game "Rogue Forest", I write the forest map on Layer 2... and originally, that layer looks to have random data on it. Is it? Or is it a pattern? I took two screen shots (ok only two), and they look like they might be completely different to me, which would suggest "totally random". But of course TOTALLY random is impossible. I was just wondering. Actually, I was wondering if that's EXPLOITABLE by me in my games? A totally[sic] random set of data with each new boot-up?
  14. Stefan> What happens if you reduce the clock speed? Lorin> Already been tried. It doesn’t have an effect. In a way, I think that's a good thing.
  15. There is a true (Apple) BASIC interpreter in CPAN, that's been there for something like a decade. I didn't use it, although I could if I needed to. https://metacpan.org/pod/Language::Basic And I believe I know the guy who wrote a JavaScript BASIC interpreter (again, Apple). Yep, here it is: https://github.com/inexorabletash/jsbasic
  16. Thanks Tom. I think I agree with you -- uh, more or less. And it's already disappeared from Wikipedia. But, I've created a new merge request on X16-docs
  17. It's not very sophisticated, and it's not a BASIC parser. What it does, though, is provide some nice features: * Labels. You can write BASIC without line numbers. And it's refreshing. * Variable labels. You can write as if BASIC 2.0 allowed long variable names. This is similarly refreshing. And my script will complain if you re-declare one. What does this get you? Read on. * Labels with dots. You can use the period in label names. What does this get you? Read on. * Variable labels with dots. You can use the period in variable labels. Why? * Multiple files. You can split your BASIC up into multiple source files. This is essentially a measure of syntactic sugar. And you still have to be careful. But. As long as you're careful, it gets you LOOSE COUPLING and HIGH COHESION with your program segments. Here's how: 1. Treat each source file as a subsystem. An object, if you prefer. For example, you might have a file named record.list which contains data and subroutines for managing "records" in your program. The rest of your program shouldn't care WHAT those records look like or HOW they're managed. You just need to expose subroutines that manipulate the data in needed ways.... yeah I mean an API. 2. Give each source file its own long variables. 3. Name these variables as if they were fields in structures. For example: longvar \record.name r0 longvar \record.strength r1 longvar \record.xp r3 4. Encapsulate your longvars with subroutines, using labels as entry points into "methods": {:record.tostring} o$ = \record.name$ + ", " + \record.strength + \record.xp return Voila. Each file could have its own API, and its labels look like method calls (even though they're not). Again, this is SYNTACTIC SUGAR. What's the big deal? Well suppose you're editing main.list, and you want to manipulate some records. If you define a nice API, you could do it like this: ; ; CONTRIVED EXAMPLE ; (p.s. these are comments that won't show up in the "compiled" BASIC 2.0 file) ; (you can still use REM for preserved comments) ; \sort.format$ = "asc" :gosub {:records.sort} gosub {:records.rollup} gosub {:records.print} Ever lose your variables? Ever have to write them down in a notebook? Do you STILL have to write them down in a notebook? NO -- if you're careful! Question. In the above fragment, where is records data managed? I would guess you put it in the file named "records.list". And where are the subroutines records.sort(), records.rollup(), and records.print()? Same place, I'd say. And if you did it that way, then you'd find it much easier to: 1. Keep track of your variables 2. Keep track of your subroutines 3. ENCAPSULATE your logic based on your data It's not foolproof by any means, and it doesn't simulate any nice flow control like while() and for(;;). But... but it does give you a way to break down your code into conceptual pieces, manage your variables, and even provide a form of "trusted" encapsulation. You're free to violate all of this, but the point of the script is to help me manage my code. Maybe it can help you as well. Or inspire you to write something better. It requires Perl. But then, doesn't every great tool? (Ha!) basic-labelmaster.pl
  18. Great minds think alike. I backed up the content to my file system yesterday. Maybe I'll add a MR to the docs repo.
  19. It's been marked for deletion (that was fast!). They can't find significant discussion on the topic to warrant its existence, I suppose.
  20. https://en.wikipedia.org/wiki/Commander_X16 I used the VIC-20's entry as a guide. I'm sure the page needs work.
  21. THE FUZZY PROBLEM I've divided the screen into a few areas. Call them windows or something. Each window represents a view into some data in my program. Often they are lists, and I feel like I ought to have a generic handler to manage this. Tell me your thoughts, including if you think this is over-optimization. ONE FUZZY SOLUTION Arrays. Shove everything into arrays and deal with it that way. For example, the metadata required to define all my windows of list data might be: (WARNING: pseudocode follows) // index is the window number. dim window_top(n) dim window_left(n) dim window_width(n) dim window_height(n) dim window_lines$(n,30) dim selected_line_of_data(n) Right? And then all I'd need is a subroutine that uses some index variable to draw the appropriate window. Insane, you might say? I'm overthinking it? Or not thinking enough? Anyone? Attached is the bare frame with nearly no content...
  22. In the name of loose coupling and high cohesion, and in the hopes that I can actually put it together with a low amount of pain, I'm organizing my code. Star Trader has many subsystems -- it has a neighboring systems chart, it has a ship status bar, it has a menu system. It has astrogation, prospecting, survey, trade, and combat. But each of those are separate modules, and most of them don't interact with each other. [ core code ] ===== [ subsystem ]+ So the core code interacts with the subsystems. The subsystems don't interact. I hope. Much. As much as possible, data is stored in RAM banks -- the star charts, character data, starship data. Bank 1 - 1K - Game-state data. Not much there now, but... Bank 2 - 1K - Player data, with plenty of room free for special stuff. Bank 3 - 8K - Starship configurations (I've filled this bank up completely). Bank 4 - 4K - Trade matrices (I pre-calculated base trade values between world types to speed up the engine). Bank 5 - 4K - If I manage to add in "mail", then messages might well go here. I estimate no larger than 4K (but not sure). Banks 11-19 - 8K - Local star charts sit here, with Bank 15 always being the 'current' subsector. They only really take up 4K each, but that leaves room for special stuff. I'll probably need more tables to handle combat and survey, and maybe to help manage a menu system.
  • Create New...

Important Information

Please review our Terms of Use