Jump to content

SmittyB

+AtariAge Subscriber
  • Content Count

    430
  • Joined

  • Last visited

Community Reputation

794 Excellent

About SmittyB

  • Rank
    Moonsweeper
  • Birthday 10/06/1992

Profile Information

  • Gender
    Male

Recent Profile Visitors

7,618 profile views
  1. I just realised that through the power of Dropbox I can post more details now. Below is the command I use in a batch file to adjust files. Convert is one of the image magick programs and this takes a file I drag to the batch as a parameter, changes the bit depth, then saves over the file I gave it. You might want to back up the graphics before running them through this if they're your only copy. convert %1 -depth 4 %1
  2. Those warnings can be ignored (at least in every case I've come across so far). It's related to how the conversion process is handling your graphics files so nothing is wrong with your code and it will import fine anyway. I use image magick to convert to 4BPP and it corrects those warnings at the same time. I can post more details later.
  3. I keep coming back to this thread trying to think of something to adequately describe what I think of your latest piece, but I can't. I give up so I'll just say it's really good and I think every part of it is spot on.
  4. I've considered doing the same thing with a gameboy. You should go nuts and stick a wah pedal in there somewhere.
  5. I believe the tolerances on the cartridge port are tighter on the 7800 than on the 2600 so a number of 3rd party cartridges won't fit and forcing a cartridge in will split a plastic cartridge guide piece inside.
  6. As the trigger is just a button it would be trivial for the game to detect the position of the gun each frame while the trigger is held. Most games flash the screen white while reading the position of the gun to make the screen as bright as possible to make it easier for the light sensor to pick up, but it's not necessary if the screen is already bright enough. Though I have both the game and the gun I've not tried it so I'm assuming it doesn't flash because that would be horrible if it did.
  7. Ah, I see. Well there's no harm in a little copying and pasting to achieve the same thing. Thanks.
  8. Something I've been thinking about that I'd love as an addition (though it wouldn't be useful to me any time soon) would be the ability to import graphics to areas of ROM outside of the usual graphics banks. The reason is a couple of the projects I have in mind for the future would benefit from setting CHARBASE to a location in RAM and loading in / modifying tiles on the fly and as part of that the tile data in ROM would just be copied around like any other data freeing up the usual graphics banks for sprites which would benefit from holey DMA unlike tiles. At the moment I would probably do it by importing graphics into a dummy program and then copying the data from the output assembly file.
  9. The short answer is CRTs only. The long answer is maybe if a game used sequential targets, was programmed to have an adjustable delay between frames depending on the player's TV, and the brightness of the LCD was cranked way too high. It wouldn't play smoothly if it worked as you'd have a long delay every time you pulled the trigger.
  10. I'm glad that something of a fix has been found and seemingly confirmed. One thing I am concerned about, although it's sort of already happened, is the schism between vox and vox+ owners. Are we going to have a situation where a game is just not playable with the vox+ unless they make this modification? Knowing that I will never own a Vectrex I'd be happy to risk breaking my current AtariVox cutting pins. I don't actually own any vox compatible games yet because I got it for development and even that is problematic with these issues as I have to keep restarting the vox if I happen to stumble across a combination of sounds / commands / timings / whatever that it doesn't like. Of the pins on the PIC (shame it's the only chip soldered down) which would need cutting if not all of them if I were to go ahead with this? Of course I'd take full responsibility for my actions in following any advice from this forum regardless of the outcome.
  11. To be specific it's exactly twice as much. 160A mode is 2bpp (bits per pixel) so each pair of bits represent the values 0 to 3 for each pixel, and you get 4 pixels per byte. 160B mode is 4bpp so you get the values 0 to 15 for each pixel but it only defines 2 pixels per byte. You don't get 16 colours though because 4 of those values represent transparency. The reason you need to keep it in mind is because the way the 7800 works to draw something it counts the number of bytes and not pixels and for some things there's a 32 byte width to what can be drawn in one go. The 7800 can also only read so many bytes per frame so it's easier to hit that limit. On the other hand if you compare it to the technique of stacking sprites to get more colorful object's as was the only option on other consoles it's a much more efficient method, stacking 2 sprites would take the same space to store but would still only give you 6 colours (plus transparency) and not the 12 you get with 160B.
  12. 160B mode graphics use either the first or last 4 palettes so you assign your colours to p0c1 through to p3c3 or from p4c1 to p7c3 and then when you draw your 160B graphic you specify either palette 0 or palette 4 to choose which colours you're using. As for variables you have 100 in var0-var99, 26 in a-z, and 1535 bytes in a large chunk from $2200 to $27FF.
  13. I've always wondered what makes one light gun more accurate than another; The quality of the light sensor? The strength of the lens? Of course looking at the Crossbow source code it looks to me like they could only get it to poll fast enough to detect 15 horizontal positions per line so maybe the difference in hardware is negligible compared to the game handling it.
  14. Another small milestone passed. After a few days of puzzling over an infuriating bug which turned out to be caused by an 'inx' a few lines before where it should have been I now have password/HSC/Savekey saving working properly. I had the bare bones of saving briefly in a previous build but it had a few bugs which I've fixed and I can now obscure the data by shuffling the bits around. For my sanity while testing I've added the ability to reset the saved password to all zeroes by holding select and reset when powering on.
  15. Each of the 7800's graphics modes have a number of drawbacks and the 320 modes are the most restrictive. One of the biggest issues with the 320 modes is the behaviour of transparency which, unless it is disabled entirely, adds additional restrictions to how graphics can be drawn.
×
×
  • Create New...