Jump to content

rje

Members
  • Posts

    1079
  • Joined

  • Last visited

  • Days Won

    34

Everything posted by rje

  1. rje

    Rogue Forest

    Version 1.1

    157 downloads

    This is a Rogue-like game, where you hack your way through a dense forest in search of a way out. Also, there's a rumor that the fabled Amulet of Yendor is lost somewhere in this forest. What a feather in your cap it would be to return with that! The map is revealed as you explore. Aside from the Amulet, there are three other kinds of treasures -- weapons, armor, and food. Weapons and armor vary greatly in their effectiveness: pay attention to their descriptions and you'll learn which ones are better. There are 31 monsters in the forest. They are currently differentiated by name only. Movement is via the cursor keys. Trees are impassable, and usually immovable. Escape the forest at the eastern or western borders. "Bump" a treasure to inspect it. There are no traps, so all treasure is safe to check out. "Bump" a monster to attack it. If your hit points reach zero, you're dead. Press the spacebar or the period (".") to rest and regain one hit point. Type "e" to eat some food, if you have any. Hunger greatly reduces your combat ability!
  2. I'm going to take this to a "Rogue Forest" thread, now that y'all've helped me fix the slow map!
  3. Updated. The monsters scurry towards you if you're in range, and they'll attack you. You can't die, yet. The forest is a bit claustrophobic, often consisting of narrow corridors and small clearings. Monsters can't step on you or other monsters, so they'll tend to block one another. You can't step on them, either, so they'll also tend to block your way. It's a feature. Treasures are currently of two kinds: weapons and armor. Armor is currently useless, but weapons boost your attack. I am thinking that the Axe weapons should be able to clear bits of the forest, slowly. The UI is still rough. The Amulet of Yendor doesn't benefit you, yet. ...But it's getting there, and the game is still, encouragingly, responsive. rogue-forest.lis rogue-forest.bas
  4. I'm thinking I should store the map in an array, even though I'm also VPOKEing it into a layer, because VPEEKs are probably slower than an array lookup. Am I right?
  5. To add my comment about that: I probably won't use the YM2151. I lack the motivation to climb the learning curve, and I don't compose music anyhow. So SID-like things are as far as I can go. I never did appreciate MIDI music, either, so maybe this is a preference thing.
  6. Ahhh, good point, I’ll have to worry about that. Instead of a treasure array, I've got a “what the monster is standing on” array for restoring the tile when it moves. This gives monsters the flexibility of, for example, crashing through “impassable” forest. Currently, only monsters within +/-5 squares (x,y) of the player move... and they move toward the player. It will be faster to just run through the monster array - I bet there will be less VPEEKing. Anyway, the monsters move, and the player "picks up" treasures. Monsters don't step on each other, so they tend to pile up when you're trying to run away. That's a nice feature. Monsters don't care about terrain features, crashing through the tree cover like it's not there. That's a nice feature, too. I want to NOT draw them when they're in the cover of the trees. The loop slows things down, so 75% of the time I skip over the current tile. It's still slow, since there's a lot of VPEEKing going on. I'll clean that up! I'm going to rename this "rogue forest". rogue-forest.lis rogue-forest.bas
  7. Just this afternoon, I realized that when I pass “-bas my-file” to the emulator, it is TYPED IN, so to speak. If I didn’t care about compatibility with the X16, then I could front-load my program with a pile of initializations in “immediate mode” without incurring the penalty of storing lines of BASIC DATA statements. Useless in the light of wanting to support the X16 as a physical chunk of hardware, so mostly an amusing observation. Unless I use that in the place of loading data files into the RAM banks perhaps... but I don’t see the benefit there, so.
  8. Tom answered it. Basically the control codes don’t make sense for VERA, right? So $40-$5f were moved to $00-1f. It’s jarring, but it is what it is.
  9. That is SO COOL. So do you have a BAM? Or maybe just a “free list”?
  10. I think I understand. You’ve implemented a doubly-linked list of dynamic strings. Instead of “pure” memory addressing, you use bank number. Do you need an extra byte for address low? Ah maybe you assume 256 byte blocks so that you have an easier time with managing the memory! On overflow, you allocate and insert a new block. Got it! You’re using a linked list, not unlike Commodore disk blocks... which are also 256 bytes. With them, the first two bytes form the pointer to the next block, so they’re only singly-linked, whereas yours are doubly linked. The final block in a disk file holds the final block’s character count and a zero. Your design is more flexible, in that each “block” (your “page”) is essentially a dynamic string with its own length. Hmmm, your addressing is like a virtual “diskette image” of up to 256 “tracks” of 32 “blocks”... with track zero off limits, used as end of file or similar... or if you looked at it sideways, 32 tracks of 256 blocks...
  11. Given the desire to entice the demo scene and make 1990s-style “Intel 80286” games reasonably possible, I can’t see the YM being dropped. However, it sounds VERY reasonable to me to have the PSG + YM2151 together.
  12. Agreed with the “single block of free ZP addresses” theory. Related to that, I’m not worried about $02-$21 workspace used by the 16-bit KERNAL... as long as pseudo registers like these don’t get scattered all about.
  13. Thanks for this... a sprite editor is needed for the X16!
  14. This is very clever, thanks! Hmmm and it might be useful for creating banked data.... Would it make sense to use the function keys in addition to control-keys? Do you always save starting at bank 1, or is the page command used to flip through banks?
  15. Pretty Cool Board! (Has Peri already done that one?)
  16. We’re the fans and we get it mixed up. All the more reason for the wedge shortcuts like CMD or whatever is preferred, in my opinion! The mental load is not worth TYPICAL usage!
  17. Thank you for this! The X16 is clearly overpowered.... but your post gave me one insight as to WHY that’s a good thing. i already noted the demo scene, which I hope will be attracted to the X16. But I’m talking about us programmers who, let’s face it, are used to the sloppy bigger languages. We’re used to having ooodles of memory and probably will only enjoy a certain amount of data limitations. in other words, there’s a bell curve here. Offer 32K of RAM.... and that’s it.... and you could cause undue pain for developers. Offer too much memory, on the other hand, and you’ve passed beyond into the absurd, or even beyond the 6502’s ability to handle memory reasonably. Note the 8 Bit Guy’s second video on his Dream Computer. When he talks about performance, he is roughly aiming for the Intel 286... in speed, video, and memory. A 6502 architecture with 80286 specs is the upper end of the chip’s reasonable reach... it’s a good upper end, with enough “slop” to spare for us programmers to enjoy an 8 bit retro experience. And that feels about right to me.
  18. I completely agree with that sentiment, Johan! At what point does retro become absurd? Why can’t I be satisfied with the limitations of an 80s architecture? It’s those limitations that allow me to create, in the first place! And the VERA chip is by far the most complex thing to work with (that I know of) in the X16. It’s a bit frustrating when you have to manipulate bits with BASIC. i imagine the power of VERA, and the sound generators, will be robust for the sake of courting the Commodore demo scene. OK, I grok that - it’s a vibrant community and worth the serenade. As for my end, i will be thinking about ways to alleviate my pain... BASIC extensions to perform sprite ops sounds like a place to start. And sound commands.
  19. Okay, we're moving the right direction!! I've got the random forest (1/3 impassable trees), and the player placed in the de-fog zone. The trees are impassable, and there's a top and bottom border that's also impassable. There are treasures and monsters scattered about, but they don't do anything. There's also the Amulet of Yendor placed -- it also doesn't do anything. These are all MAP features. That means when monsters eventually "move", I'll have to VPOKE the map. I record the address of the monsters, and I only allow 32 monsters. I haven't thought up a good way to "know" when the player is "near" a monster. I can loop through the monster addresses, if it doesn't slow things down too much, or I can figure out something clever -- for instance, a quadtree-like approach to the monster locations, storing them into buckets based on general area of the map. I've attached the importable BASIC, as well as the original listing, which I use because I'm old and spoiled on things like labels. It's my own flavor, which I transpile with a Perl script -- again of my own making -- to Commodore BASIC. scary-forest.lis scary-forest.bas
  20. Now as for sprites... OK, I wrote some sprite demo code for the X16... but I think it's r37 code. And we all know that the VERA registers in r38 is a bit different. So.... maybe I want to wait. Maybe I'd rather print PETSCII in front of the background layer. ALTHOUGH, if I'm careful, maybe it only affects an offset, like so: 100 S0 = $5000 :REM OFFSET 110 VPOKE $F, S0+0, %00000000 :REM LSB 120 VPOKE $F, S0+1, %10001000 :REM MODE=8BPP(7); ADDR = $10000(0-3 + LSB << 5) 130 VPOKE $F, S0+2, 220 :REM X = 220 140 VPOKE $F, S0+3, 0 :REM (X MSbit) 150 VPOKE $F, S0+4, 55 :REM Y = 55 160 VPOKE $F, S0+5, 0 :REM (Y MSbit) 170 VPOKE $F, S0+6, %00001100 :REM Z = LAYER 2, NO H/V FLIP (0,1) 180 VPOKE $F, S0+7, %01010000 :REM H=16(6-7), W=16(4-5) 200 FOR I = 0 TO 3519 210 READ X 220 VPOKE $1, I, X 230 NEXT 300 VPOKE $F, $4000, 1
  21. It occurs to me that, in order to be safe from the 2.0 garbage collector, I might want an array of position-strings... but I wonder if it matters. (And, I read an ooold Butterfield article that hinted that BASIC 4.0 didn't have the GC problems that 2.0 has. So, shouldn't we be forking 4.0?) po$(0) = "{home}" po$(1) = "{home}{down}" ... po$(40) = "{home}{down}....{down}" (forty {down}'s, you know) ...
  22. I. THEORETICAL Taking cues from the 8 Bit Guy's video on his "Dream Computer" (part 2). 1. I assume that "Planet X16" will be distributed via diskette. 2. I assume that the 8 Bit Guy will load the game map and data into banked RAM. 3. Ultima VI is one of his favorite 8 bit games. On the C64, it came in six diskettes, roughly taking 1MB of RAM. Given those three assumptions, the Law of Resource Estimation suggests you take your requirements and double them. If you think you need 1MB, then make sure you have 2MB. * * * II. PRACTICAL The "full load" option is a good one. You could load everything, instead of swapping files in and out, if you wanted to. You could load whole diskettes from IEC drives, if you wanted to. This could make *diskette* distribution "more" viable as an option -- again, if you wanted to. Doable options that fit well with the overall design.
  23. Greetings Timmy! I spent the first half of my life in AZ, and Commodore was strong there in the 80s. I think the X16 will make its mark in the retro space in the 20s.
×
×
  • Create New...

Important Information

Please review our Terms of Use