Jump to content

StephenHorn

Members
  • Content Count

    230
  • Joined

  • Last visited

  • Days Won

    14

StephenHorn last won the day on September 3

StephenHorn had the most liked content!

Community Reputation

206 Excellent

4 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah, the million-plus starting price is the giveaway, as far as I'm concerned. eBay doesn't do that many figures.
  2. In terms of "not overflowing", I got nothing. I guess either hard code the appropriate boundaries or carefully choose the data so overflow is impossible. Abbreviate select words and whatnot. For instance, Megaman games almost always abbreviated weapon names like "M.Buster" for the Mega Buster. I forget who said it here, it may have been John Gill, but someone was saying that there's just no getting around it: You have to plan carefully. I think that's very sound advice.
  3. I think your conclusions are correct. I'm actually a little surprised the kernal is where support is implemented for using the keyboard as a joystick. I would have expected the emulator to pass along keyboard state data, but I can't recall ever looking into it too deeply. I'm not all that surprised that the BASIC command does not support the second byte of data, especially after reading the documentation for JOY on BASIC 3.5. If the goal of BASIC was to maintain backwards-compatibility, then JOY will likely never support more than the D-pad and one additional button.
  4. Unfortunately, the only thing I wish could be revisited is the 640x480 resolution, just because it's proving hard to find new monitors that will natively support that resolution. Folks support 5:4 multiples close to that, and 16:9 multiples close to that, but when it comes to 4:3, the closest you tend to see is 800x600 or 1600x1200. I don't understand why monitors worked out that way, but... well, they did. A pity. That's hindsight for you, though.
  5. The emulator was programmed to contain random data because supposedly that mimics the hardware's state. I couldn't tell you whether that's an assumption or whether that was informed by conversations with the VERA's designer, Frank van den Hoef. Since Frank wrote the original implementation of the VERA emulation, I'm assuming it's how the hardware actually behaves.
  6. Proper pathfinding was not common in games of the time because of how expensive they are to execute. Even games as late as StarCraft didn't implement "proper" pathfinding such as A*, instead choosing various strategies to "wrap around" obstacles and get out of problem areas. Actually, since players' expectations for map size has increased almost as much as the CPU power required just to manage and draw those maps, pathfinding has remained a difficult problem, with novel solutions still being invented, which all have pros and cons under varying circumstances. So don't worry if you never get A* running at speed on an X16. :3
  7. I don't have time to find the exact location of his solution, but didn't Ben Eater do some kind of clock division for his homebrew VGA circuit?
  8. Mostly correct. The one caveat is to make sure you stz $9F25 to make sure you are setting the VRAM address of ADDR0_x, instead of ADDR1_x. ADDR0_x is accessed through $9F23. ADDR1_x is accessed through $9F24.
  9. Thanks for the update, Lorin. It must be absolutely maddening for everyone on the team to be so close to launching the fundraiser for production, but for the bugs. Good luck!
  10. It's funny you should mention "at a reasonable speed", because even modern game engines struggle with "the bullet problem" -- what happens when an object is moving so fast that its entire volume can travel from one side of an obstacle to the other within the span of a single frame. Actually, in some ways, the problem is harder today with rigid body physics, where you don't typically express world geometry in terms of "volumes" and instead reduce it to a series of surfaces. This means it's actually easier for small objects to move fast enough that it appears to "pass through" the solid surface. Typically, modern physics engines attempt to resolve this problem by taking multiple interpolating steps from a start position to its end, hoping that by taking smaller "steps" within a frame they'll detect this kind of condition. This is why collision quality in engines like Unity or Unreal have multiple settings, so a large and slow object can skip the extra interpolation, while literal models of bullets, traveling at bullet-like speeds, can hog all the CPU time by making many hundreds of steps between each frame. Of course, for bullets and the like, many 3D games these days also choose not to simulate bullets at all, they just cast rays into the scene. These games' behaviors are commonly referred to as "hitscan". Overwatch, by Blizzard, has a number of heroes which use hitscan weapons, while others use finite-speed projectiles. But you can find bullet-speed projectiles at least as early as Max Payne, which has a bullet-time mechanic where you can see the bullets traveling. It's also possible to calculate the bullet trajectory from one frame to the next and then raycast along that segment of the path, which has its own pros and cons (this can be inefficient if there are a lot of bullets in the air at one time). So, "a reasonable speed" has always been an interesting problem, if you're trying to push the envelope for some reason. I suppose, putting my game designer hat on for a moment, the question is: Why do you need bullets that small to travel that fast? Like, what's the purpose, and would it be just as well to make the weapon's attack instantaneously travel along the line?
  11. All I can really add is that is was common for games of the period to rely on simple axis-aligned box logic to detect collisions - this is where the term "hitbox" comes from - because it was frequently considered way too expensive to have pixel-perfect collisions. It was a requirement, then, that the graphical assets to conform reasonably well to some minimal set of hitboxes (in games this was typically 1 or 2 boxes total for the player, and 1 box for enemies, but needs varied). A helicopter game where the heli is viewed from the side and can actually tilt in the direction of movement would be difficult to express in such hitboxes, so might require some special case logic. I would think this is fine as long as we're talking about 1 such special object in the scene, but I wouldn't expect there to be an abundance of processor power for, say, enemies to have the same kind of collision logic with random objects.
  12. $1F9C1 is Frequency word (15:8) in the VERA's PSG. Assuming $1F9C0 is $00, this is setting the PSG's frequency to 381.47Hz, somewhere between F#4 and G4. I would assume the intention is to produce G4, so you would want to set $1F9C0 to $1C.
  13. A straight translation into 6502 assembly would be: lda #$00 sta $9F25 ; Set ADDSEL to 0 lda #$C1 sta $9F20 ; Set ADDR0_L to $C1 lda #$F9 sta $9F21 ; Set ADDR0_M to $F9 lda #$01 sta $9F22 ; Set ADDR0_H to $01 lda #$04 sta $9F23 ; Write $04 to VRAM addr $1F9C1
  14. In that case, my vote is the same shade of white as the premium WASD keyboard.
×
×
  • Create New...

Important Information

Please review our Terms of Use