Jump to content

Ender

Members
  • Posts

    171
  • Joined

  • Last visited

Posts posted by Ender

  1. On 10/19/2021 at 12:02 AM, ZeroByte said:

    The Background actually has 17 layers of scrolling. The clouds/tall mountains are the main BG scroll value. I created a table of 16 raster line values and the demo cycles through these, setting each one as the next line IRQ to trigger on.

    When the main loop begins, it creates a table of scroll offsets based on the main BG's scroll value (which is 1/8 the FG scroll value). It divides BG scroll by 2 to create a "per line scroll amount" (delta). On each raster IRQ, the BG scroll is incremented by delta. After 16 iterations, the bottom row of water ripples will be scrolled at the same amount as the FG (this happens below the path, so you don't see it scrolling at the same speed as the FG though). All values (FG, BG, and per-rasterline) also keep a subpixel scroll amount, so the speed is very flexible - as low as 1/16 of a pixel per frame (FG scroll). This subpixel scroll amount is maintained through the creation of the 16 raster scroll values as well in order to keep it nice and smooth.

    I did cheat for Sonic's Y coordinate though. The tile set is arranged very erratically. I'm convinced there must be meta-data in the tile numbers to indicate things like "vertical offset" that I'm just not seeing - and making a table of varying terrain heights from tile IDs was crazy, and required a linear search through the table, just to determine something as simple as how high Sonic is with the ground. So since the BG is fixed and repeating, I just fudged and made a "per column" table by hand and have the game cycle through that table with every 8px of scrolling performed. It works for this demo, but if I were to have more varied terrain or vertical scrolling for things like jumping or higher platforms, I'd have to do a lot more work to make Sonic properly collide with tiles. Not necessary here, so I took the path of least resistance. 🙂

     

    I thought I'd seen something about how collision detection in Sonic worked, and looked around some and came across this. Looks like it could be interesting to you: https://info.sonicretro.org/Sonic_Physics_Guide

    In particular, https://info.sonicretro.org/SPG:Solid_Tiles and https://info.sonicretro.org/SPG:Slope_Physics

    • Thanks 1
  2. On 10/15/2021 at 5:38 PM, Scott Robison said:

    David has said that the X8 is not a plan going forward as it turned out to be too different, and that Frank was looking at something that could be more like the X16. So I think you need not worry about fragmenting the ecosystem in that way. Maybe some other new and improved way, but not that way. 🙂

    Yup, I was relieved to see that.  I was about to say I'm still a little skeptical that that's actually what he meant based on the wording in the screenshot that's been circulating, but I did some searching on the Facebook group just now, and apparently they've come to the same conclusion, and I'm sure they would have been corrected by David or Frank there if it wasn't true (since they both seem to regularly post there).

    Don't get me wrong, the X8 does sound cool, and I would probably buy one at some point, but I'd just feel better if the X16 came out first.

  3. Most people have shrugged it off, but I still worry about having two incompatible systems out there, competing for software development resources, especially if the X8 comes out first.  I'd much rather have a X16 FPGA solution come out first instead.  It would be fine if the X8 were to release eventually (although once the X16 comes out I don't really see the point), once the X16 software ecosystem has matured a bit.

  4. On 10/12/2021 at 9:55 PM, Scott Robison said:

    VPOKE will set an address (I don't think it's documented as to whether it will set addr 0 or 1), but I don't think it sets the increment. Regardless, VPOKE will always reset the address every time it is used. By avoiding VPOKE completely you can set the address, pick whether it is 0 or 1, and target the port. Whether it is a net improvement will depend on how much overhead is involved in the multiple POKE statements and how many bytes you write with auto incrementing addresses. I feel confident that my solution is technically correct (though I didn't try running it), but it might not be more efficient than a series of VPOKE statements. That would probably be a good test. Run the 8 VPOKE based version 1000 or so times and time it, then run the 12 POKE only version 1000 or so times and time it and see if one is definitively better than the other.

    Now I'm curious. Testing. 🙂

    If you look at the source code of VPOKE, all it does is put the first argument in to $9f22, the second argument into $9f20 and $9f21, and the third argument in to $9f23.  So yes, you can use VPOKE to set the increment, and arguably it's faster than doing three POKEs to set up the address, since you're parsing and executing two less BASIC commands.

  5. If you're using the initial VPOKE just to set up the address, that won't work since it will increment on that write as well, and it will end up starting at P+1 on the next line.  You need to start at P-1 (assuming that it's ok to put a 0 there), or somehow VPOKE only on the first actual data write that you do.

  6. Correct me if I'm wrong, but you have SPRITE_64_BY_64 set to 196+48, which is 244, which I believe is 0b11110100 in binary.  This results in a palette offset of 0b0100.  I'm guessing that's not what you want since your palette_offset is 0.  I think what you want is 240 for the dimensions.

    • Thanks 1
  7. 3 hours ago, rje said:

    Yeah, I'm using 38, but I always specify the address so the contents of those two bytes don't matter to me.  I always write two zero bytes when I create these images.

    Right, but the bug is that it will always use the first two bytes of the file for the address, so if it's 0, it will try to load it to 0.  Only if you're using an SD card image though.

  8. I've currently got a Cooler Master Masterkeys MK750 with Cherry MX brown switches.  I'm pretty satisfied with it, it's my first mechanical keyboard.  I was kind of afraid to get keys that were too loud, but after having some experience with a mechanical keyboard and watching a bunch of videos on blue keys I kind of want to try buying some blue keys for it and see how I like it.

  9. 1 hour ago, rje said:

    OK, so I have the debugger up.  I can see memory locations by using the m xxxx command -- for example, to see RAM bank 4 I can do this:

    
    b ram 4   
    m a000     (actually, this command appears to ignore the bank set and always displays bank 0)
    

    Now VERA's memory is.... in VERA.  What's the debugger convention for displaying VERA?  The docs don't say (https://github.com/commanderx16/x16-emulator), and trying something like "m 14000" defaults to 0x4000.

    You can see VRAM with the "v" command.  Like "v 10000".  It hasn't been added to the documentation yet, probably because it originally came from a pull request.

    • Thanks 1
  10. I think it's definitely possible to do a simple (well, "simple"), line-by-line converter that detects when you're writing to a C64-specific area and converts it to an equivalent X16 area.  The same for converting graphics calls to equivalent VERA calls, etc.  The only thing is, as people pointed out, in a lot of the more complex cases, such as demo scene stuff, that would probably end up being slow, since the various techniques to accomplish things on the C64 would not always be the best way to do things on the X16.  So it's definitely possible, just that it would have a limitation of being slow in a lot of cases.

    • Thanks 1
  11. I'm not sure what your question is.  Do you mean is there a way to load an SD card image after you've started the emulator?  There isn't currently a way, no.  That's just a limitation of the emulator.  If you want to load a different SD card image, you have to restart the emulator with a different command line.

  12. 2 hours ago, Colin said:

    I have read through most of the thread, so I don't think this has been asked or discussed, maybe I missed it.  Why can't the case be included with the kit?  I would purchase a kit version of the X16, but it would be more attractive to me if the case could be included.  Is it that anticipated sales of a kit version would be way below the minimum 1000 units that the case manufacturer requires?

    Well, David describes in his post that it would require renting storage to store all those cases, and a lot of manpower and time to package all of it, and he just doesn't have the time or money to do all of that.  I guess when he initially formed the idea he wasn't thinking they would have to deal with 1,000 units all at once.

    • Like 1
  13. I would think that a license like that, (that is, one that makes you credit the author but not copy the license) kind of defeats the purpose, wouldn't it?  Because let's say someone derives from your work and credits you but doesn't copy your license.  Then someone else can derive from their work, but since there was no license, they don't credit the author.  Then it can spread from there, with no credit to the author being given.  I think the copying of the license kind of needs to happen, for it to have any effectiveness.

    • Like 1
    • Thanks 1
  14. @BruceMcF Are you saying then that the range of CPU RAM directly maps to the VRAM from a hardware perspective?  That makes sense, I didn't know that.  The way I imagined it was just how I interpreted David's wording in the original post, but I don't know a lot about the hardware side, so your way probably makes more sense.  (Technically though, you could use it as CPU RAM if you really wanted to 😄).

  15. 1 hour ago, TomXP411 said:

    I’ve got a real 128, although I don’t pull it out often. When you get ready for Beta testing, let me know. 

    I have a C128 too actually.  It's from when I was a kid and I have no idea if it still works (it hasn't been powered on since the mid 2000's I think), but I could finally dig it out and see if it still works if you want another beta tester!

    • Like 1
  16. Wow, congrats.  I wish I'd thought of that first, I'd be psyched to work on something like this (although I don't have much experience working on the C128).  I kind of want to ask David for the source code anyway, mostly just because I love looking at other people's code and seeing how they do things and learning from it, and I'm sure the PETSCII Robots code is interesting.

    • Like 1
  17. 3 hours ago, John Chow Seymour said:

    So when the CPU is writing to the area that is acting as the 'window', it's writing to VRAM instead of CPU RAM? Or the write affects both RAMs?

    As far as I understand, it affects both.  The changes to the window in CPU RAM are mirrored onto VRAM, and where these changes are mapped to in VRAM can be controlled by a register.

    • Like 1
  18. 2 hours ago, John Chow Seymour said:

    I'm wondering if someone could, very briefly, explain/summarize the difference between these two graphics approaches.  (Not necessarily @paulscottrobson, your post was just a handy one to quote that mentioned both.)

    I'm not a graphics guy at all (all my work in assembly has been SIO/text, or sound), and for either the X8 or the X16 I would have to learn how the graphics system works.  For anyone else on the forum here who might fall into that same boat, the briefest of comparisons might aid the discussion.

    Not a tutorial on how to use the two, just maybe a 1-2 paragraph overview, would be greatly appreciated. (Apparently the 'window' approach requires more pins on the FPGA - why? Does one or the other demand more of the CPU's cycles? etc.)

    If such an explanation already exists (possibly in another thread) then I apologize and would appreciate a link.  Thank you!

    Not really sure what you already know, and what you're asking for, but I can summarize it from a software standpoint (no idea about the hardware side/feasibility of setting up the X8 to act like the X16).

    On the X16, the way you write to the VERA is to write to specific addresses ($9f23/4).  When you write to these addresses, the data is automatically transferred to the VERA.  You can set the address on the VERA it's written to by writing to the addresses $9f20-2.  The VERA also has a feature where you can set it to auto-increment the address for you so you don't have to worry about that.

    On the X8, there is a 256-byte window that you can write to that is mirrored to the VERA, rather than writing to the two addresses.  You control where on the VERA this 256-byte window maps to.  This is convenient for loading right from disk into the window, for example.  Besides that though, (and I haven't thought about this a whole a lot so take this next part with a grain of salt), but from a VERA user's point of view, implementing a game or something, it doesn't seem that much different to me, besides that you're incrementing the address you're writing to yourself as you write into the window, rather than letting the VERA handle that for you. You also have to worry about changing the window address every 256 bytes.  So honestly, it seems more complicated to implement for than the X16 to me.

    • Like 2
×
×
  • Create New...

Important Information

Please review our Terms of Use