Jump to content

Asmusr

Members
  • Content Count

    3,710
  • Joined

  • Last visited

  • Days Won

    13

Asmusr last won the day on September 21 2019

Asmusr had the most liked content!

Community Reputation

5,155 Excellent

4 Followers

About Asmusr

  • Rank
    River Patroller
  • Birthday 07/21/1970

Profile Information

  • Gender
    Male
  • Location
    TI-99/4A epicenter

Recent Profile Visitors

25,001 profile views
  1. https://js99er.net works quite well on a phone, but you need tiny fingers to access the keyboard.
  2. Yes on the CPC you could choose 2, 4, or 16 colours (depending on the mode) from the bigger palette of 27. That was really advanced for its time. The F18A can do much more, of course, which is why a started this topic. If we had a better but compatible palette, it would be simple to allow F18A owners to choose that in a game without changing the graphics.
  3. JS99er should work directly with controllers compatible with the Gamepad API. I think mine is an Xbox controller. https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API
  4. That's what I'm not clear about. For example: Texture height: 64 Run height in texture pixels: 5 Sprite height on screen: 38 Size of unrolled code (height=38) in bytes: 172 Fraction of code to run: 5/64 = 0.078125 Number of bytes to run: 0.078125 * 172 = 13.4375 Number of screen pixels drawn: 0.078125 * 38 = 2.96875 Clearly we cannot execute 13.4375 bytes or draw 2.96875 pixels, so I think the encoding routine would need to keep track of these fractions for us, and tell us exactly where to call the code (or how many screen bytes to skip), at a given scale.
  5. It was my plan to do something medieval and dungeon like, but since the color palette makes that difficult my current plan is to do something 'abandoned tech'/sewer like. The current selection of monsters doesn't really comply with that, so if I don't want to draw them I need to look for a another source. The current weapon you could think of as a thrown rock, which should apply to any setting, but really the whole thing is up for debate - also the way of controlling the game, which could be changed to 'mouse pointer' style. Maybe I should reserve some screen space for status information, and maybe the game should be turn based? The only thing that's clear is that this is not a first person shooter but more like an RPG. I'm not going to update the non-textured FPS any further.
  6. I did it, and I think the result is worth the reduced frame rate in some places. The floor/ceiling now takes up half of the 512K ROM, but it could be compressed and uncompressed to SAMS. texcaster.rpk texcaster8.bin
  7. Yes it is quite confusing to have two discussions taking place at the same time. 🙂
  8. If you're talking about a raycaster it cannot draw anything with holes or anything with variable heights.
  9. The reason it will never happen is not the hardware requirements but because it would take thousands of hours to develop.
  10. Unfortunately it cannot be the same code as for the walls because it takes one instruction to draw a wall pixel but two to draw a sprite pixel. On the other hand the sprite code is the same for even and odd columns. Are you suggesting to encode this once per texture or once per texture and scale? If it's once per texture it appears to require some quite complex calculations to decide where to call the code and what the source and destination addresses should be set to. If it's once texture and scale it appears to require a lot of space (something like 32K per texture).
  11. The textures are currently 32x64, but reducing the height to 32 would in itself reduce the overhead for handling empty pixels by a factor 2 for heights where you need to read all the texture pixels, i.e. >= 32.
  12. That sounds interesting. I'm looking forward to see some visuals.
  13. 96 for sprites and 138 for walls.
  14. I'm not sure if you're suggesting anything or just joking. Maybe, but it sounds like a lot of trouble for a rather limited improvement of speed.
  15. Having an animated floor/ceiling would reduce the frame rate almost down to how it is now when you turn and the entire screen is redrawn. But maybe a steady frame rate would be preferable to the speed-ups you experience when running through corridors if you got an animated floor/ceiling as a bonus? Removing some of the optimizations from the code would certainly make it easier to understand and maintain.
×
×
  • Create New...