Jump to content

TheMole

Members
  • Content Count

    838
  • Joined

  • Last visited

Community Reputation

675 Excellent

About TheMole

  • Rank
    Dragonstomper
  • Birthday 09/11/1979

Profile Information

  • Gender
    Male
  • Location
    Belgium

Recent Profile Visitors

8,971 profile views
  1. 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
  2. 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.
  3. 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!
  4. 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.
  5. 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?
  6. 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.
  7. 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!
  8. I also added support for 2-button joysticks to Alex Kidd, but I don't think anyone has ever used it...
  9. 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...
  10. I just tried the two first images in my home-grown F18A tiler program, and the first one doesn't load without modifications to the patterns. Now, keep in mind that this program is not designed to optimize palettes, so with some care I'm pretty sure we should be able to get it to display as-is. The second one worked on the first try and only uses four out of 8 available palettes:
  11. Hmmm, no preferred subject I can think of now, although I'm still hoping I can start work on that Activision Ghostbusters port one of these months years ;). Anything within those limitations should work! Oh, and ideally of course something within the 12bpp master palette of the F18A, so I don't have to reduce a 16bpp or 24bpp image down to the 12bpp color resolution of the chip which might affect your shading.
  12. There seem to be some technical limitations that Matthew has already highlighted which get in the way of simply extending the number of bits assigned to palette vs number of bits assigned to the pattern. I've pasted the relevant reply below: I'm not disputing that having a fully and freely selectable palette of 16 colors anywhere on the screen would greatly help you , I'm convinced it is a whole lot more comfortable for you to work with less limitations and not more. but I wouldn't go so far as to say this is how all - or even most - pixel artists feel. If I can make an analogy from my perspective as a coder, I actually enjoy the period-correct limitations quite a bit. I have very little interest in programming modern machines these days because there are so many tools out there that make it so much easier to create impressive looking results. The limitations of the TI99/4A provide challenges that are fun to try and overcome, and I have a much bigger sense of accomplishment whenever I've managed to do something that works around the limitations of the hardware. I wholeheartedly and 100% understand that not everyone feels that way, and I'm absolutely not judging those who don't. Just wanted to point out that not everyone has the same reasons for enjoying this retro computing thing. Having said that, just like everyone else I have some ideas regarding new features for the F18Amk2. I've always been a big fan of the way the Sega Master System handled it's graphics. The SMS VDP is a direct descendant of the tms9918a (it supports all of the tms9918a's modes), and does in fact add a 4bpp mode. In that mode, you have access to one of two palettes of 16 colors per tile (sprites are forced to use the second palette, no choice there). The mode is called "mode 4" in the master system world, and would be a nice complement to ECM1..3 in my opinion. But I fully understand that my opinion is just that... one of many opinions. I would prefer this way of extending the F18A, some other people might be more in favor of extensions that follow the programming model of the Yamaha 99x8 chips a bit more closely, while yet other people would like a more CGA/EGA/VGA based approach. Can't please everyone, and I for one am pretty excited to explore whatever Matthew comes up with eventually. I'm note sure if you already discovered this, but /if/ you don't mind losing half of the horizontal resolution, the current F18A actually does support a full 4bpp bitmap layer that can span the entire screen. Alternatively, as Tursi has pointed out, the current F18A in ECM3 mode actually does give you more than 16 colors on screen (up to 63, like the Sega Genesis), and is only limited to 15 colors per 8x8 tile. And that is without resorting to scanline tricks. I would love to see if we can take an image of yours and use the current F18A features to show it on screen, unaltered, using a combination of the techniques available to us. Any chance you can give me a sample of some 16 color art you'd like to get running on the system? I'd be happy to give it a go!
  13. TheMole

    TheMole

×
×
  • Create New...