Jump to content

TheMole

Members
  • Content Count

    842
  • Joined

  • Last visited

Community Reputation

678 Excellent

About TheMole

  • Rank
    Dragonstomper
  • Birthday 09/11/1979

Profile Information

  • Gender
    Male
  • Location
    Belgium

Recent Profile Visitors

9,052 profile views
  1. Ah, yes, probably! I will test again tomorrow when I'm at my computer.
  2. I think there's an issue with the uploaded image though... when I try to run it in js99er, all walls have a jellyfish texture.
  3. Some of those textures are incredibly refined, so impressive to see this on a 9918! I mean... that green metal door texture for instance, is amazing!
  4. You're right, I was looking at it on my phone and the resolution seemed implausibly high, but this indeed fully fits within the capabilities of the VDP
  5. Not sure if this is correct though. Even looking at the thumbnail of the video, your horizontal resolution seems higher than what the 9918a can display using the 4x1 macropixel method. Look at the slope of the leftmost block. That looks like it uses a 1x1 pixel resolution to me. I think you've only applied the 4x1 limitation to the textures themselves.
  6. If you drop the lower third from the screen, like in my raycaster or the megademo, you only need to transfer 4k. I believe we once came to the conclusion that we have a bandwidth of slightly more than 2k per frame on the TI. That would imply 2 frames to update the entire screen. As far as number of rays to cast goes, I've been wondering if there's a way to interpolate the calculations... Could you just calculate 32 rays (e.g. only the odd ones) and fill in the gaps by averaging the height of the two columns next to it? Sure, you'd need to have a special case for when the ray hits a new wall, but perhaps it wouldn't be too awful looking if you just copy the height of the previous column in that case... Either way, this proves that horizontal resolution is much more important than vertical resolution!
  7. Yup, this wiring would work with Alex Kidd as well, you can use J2Fire instead of J1Up for jumping, which greatly improves playability for a game like this.
  8. Ooooh, just starting out with that (using the "Look mum no computer" plans for now), really cool stuff! Do you have a blog somewhere where you chronicle your builds?
  9. I would like to see an overhaul of the sprite collision handling routines provided by extended basic. Imagine that instead of having to "poll" for collisions ala CALL COINC, one could use a callback function-like system. Prior to executing your main game loop, you declare which sprite collision combinations you are interested in like so: 100 CALL COINCSETUP(#1, #2, PLAYERHIT) 110 CALL COINCSETUP(#1, #3, PLAYERPOWERUP) 120 CALL COINCSETUP(#4, ALL, ENEMYHIT) Then, further down the program you declare the subroutines mentioned above where you put your collision handling code. E.g.: 10000 SUB PLAYERHIT 10010 PLAYERHEALTH = PLAYERHEALTH - 1 :: IF PLAYERHEALTH = 0 THEN RESETLEVEL = 1 10020 SUBEND 10030 SUB PLAYERPOWERUP ... The actual collision check would be performed in the interrupt handler and whenever a collision that the program is interested in happens the associated callback routine would be called.
  10. I love "van de pot gerukt" in Dutch, which translates to "Having been janked from the toilet". Another one is "op uw kop gevallen en blijven botsen", which roughly means "fallen on your head and kept bouncing". These things are hard to translate!
  11. I also added support for 2-button joysticks to Alex Kidd, but I don't think anyone has ever used it...
  12. It's really not a general purpose tool, and is basically a collection of hacks to help me get the maps for Alex Kidd converted from png to a raw tile format usable with the F18A. Having said that, it's an SDL program, so in theory it should run on any supported platform. I've never compiled it on anything besides a mac though. Let me know if you want to have the source code to play around with...
×
×
  • Create New...