supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
It is somewhat similar to the ground in Defender II, or the web in Krull, or a few other things, but I've never seen anyone use the triple-sprite feature with precalculated sprite shapes to produce a conformable zig-zag object. BTW, a somewhat similar technique which perhaps someone else can try coding up would be to use a 48-pixel wide sprite shifted one (or two, or 3) pixels per scan line to yield a 48 (or 24 or 16) pixel high full-resolution diagonal 'stripe' that ran the full width of the screen. Perhaps one could even construct a flicker-free 'mini-Zaxxon' game using such an arrangement.
-
No, actually. The Atari 2600 is basically limitted to displaying a maximum of 48 pixels worth of sprite data per scan line, or if you really want to push things 56 (or maybe 64) and there are pretty severe restrictions on how that data can be placed. The zig-zag shape maximizes the effective usable screen real estate over which these pixels can be spread. At the spot where the upward and downward lines of text join, the maximum width is 16 pixels. If the left and right texts scroll inward at one pixel per scan line, this gives a height of 8 pixels. If you were to try to "flatten" out the shape on the top, this would reduce the allowable text height.
Further, even using unrolled loops, the calculations required to shape the text as it went around the curve would be too much for the poor 6507 to handle. Even on the Zig demo where I made things as simple as I could, there are only about 10 cycles left per scan line.
BTW, in case anyone is curious, the Zig demo uses two bitmaps for the scrolling text: one for the upward edge and one for the downward edge. Some of the letterforms are quite noticeably different in the two bitmaps. I did this rather than using one bitmap and deforming it on the fly because (1) it's oodles faster [and thus actually doable], and (2) hand-tweaking the bitmaps for some of the letters greatly improves their appearance. A few letters deform strangely right at the "turn", but for the most part they look pretty reasonable.
-
It's interesting how some games get named as the "worst game ever" and yet have people defending them. Sometimes it's because the supporters have no taste; other times I think people give up on games as 'unplayable' even though they can be mastered with patience.
I have yet to hear anyone come to the defense of Froggo's "Karate", though. I wonder why?
-
Here's a preliminary taste of my "zig scroller" routine. Still needs some improvements, but the display is unlike anything I've seen on the 2600. The top line is controlled by moving the joystick left and right; the next line by moving it up and down. The remaining five bounce at various speeds. Pushing fire will let the joystick move text faster, and reset will restart the top two lines in their default positions.
I'll release some source code once I get everything improved to where I like it, but for now I'd be curious how well people can guess (without peeking at the code) how it all works. Anyone want to give it a go?
-
Here's a preliminary taste of my "zig scroller" routine. Still needs some improvements, but the display is unlike anything I've seen on the 2600. The top line is controlled by moving the joystick left and right; the next line by moving it up and down. The remaining five bounce at various speeds. Pushing fire will let the joystick move text faster, and reset will restart the top two lines in their default positions.
I'll release some source code once I get everything improved to where I like it, but for now I'd be curious how well people can guess (without peeking at the code) how it all works. Anyone want to give it a go?
-
Not so easy in some games where movement is tied to flicker rates. Skipping every sixth frame in such games would look horrible.
-
NTSC was invented in 1953, PAL in 1967. I can't say why the color standards were put in place, but the frequency 50 Hz vs. 60 Hz may have been due to the line frequency of the electrical outlets. Perhaps it was not easy to make a 60 Hz TV running on 50 Hz european line voltage in 1967...On older television sets, there is a fair amount of line-frequency ripple on the high-voltage circuitry, and this ripple couples through into both the electron-beam intensity and the scanning geometry. The picture will thus be a little brighter and a little wider during the active part of the line phase, and a little dimmer and narrower at the null. These differences are pretty slight, and if the line phase is constant, are not really noticeable. If the line frequency doesn't match the scanning frequency, however, the screen will appear to throb and undulate at a frequency twice the difference between the line and scan rates. Thus, if the line frequency is 60.0Hz and the scan rate is 59.9Hz (as it might be from a VCR) the screen will stretch and shrink every five seconds.
Newer television sets don't have this problem, so nowadays frame rate doesn't really matter. But in the early days of television, matching frame rate to line frequency was important (a 10Hz difference would have been horrible!)
-
Actually, looking at the color NTSC/PAL/SECAM TIA color charts ( http://www.qotile.net/minidig/docs/tia_color.html ) -- it's kind of weird how few colors SECAM has. Is the selection of colors a result of how that type of TV happens to respond to the TIA output, or is a PAL Atari different than a NTSC Atari is different than a SECAM atari?For NTSC and PAL, the TIA generates a chroma output on one pin and a grayscale code on three others. These four pins are combined with various resistors to yield a color composite signal.
The chroma output is totally useless for SECAM (System Essentially Contrary To American Method), however. What the SECAM 2600 units do is take the three grayscale output pins and feed them into a simple color generator. Too bad they didn't mix the chroma output with an amplified version of the crystal input and amplify the result to get a grayscale signal. Colors would have been entirely different from PAL/NTSC games (chroma would set luma and vice versa) but the results should be somewhat workable.
-
What'd be the fun in that? One of the joys of the 2600 is seeing a new technique and then figuring out for yourself how it's done. Plus, in some ways my code is sorta icky. But I'll probably post it pretty soon anyway.
-
Perhaps it would be better to keep this thread to Boulder Dash, and post demos and discussions of colour display technologies to another forum. Your engine looks nice. But I would advise study of what has already been done. Attached are some small colour-display demos showing Interleaved Chronocolour in action for PAL/NTSC/SECAM, and also some experiments with interlacing.Thanks for those. They're kinda cute, though my approach shimmers less (for four of the colors, shimmer is pretty minimal) >:*3. I'll leave this thread to Boulderdash, and look forward to seeing it when it's done. Yeah, I sorta discovered my scan line count was way off after I posted it; I hacked down my code to get it under 1K and sorta oopsed.
-
BTW: Since you said you've never seen a venetian color flicker thing elsewhere, I attached one for you...Hmm... that's not quite what I had in mind. Check out the enclosed demo I just wrote to see what I was thinking of.
-
I have explored many display techniques. You possibly don't realise that this current version *does not flicker at all*. My previous colour display technologies like Interleaved Chronocolour and Spasticolour used various rolling-colour techniques like you suggest. Check out some of the binaries I released on stella and in the AA forums for examples.I'll have to check those things out. I just wrote a cute little demo of a color technique that's a little different from what you're probably using; the color/BW switch toggles between 'stripes' mode and 'flicker' mode. For this engine, I think flicker mode is better, although given the amount of dirt in Boulderdash having non-flickering stationary colors is probably better.
-
I just produced a cute little seven-color paint program for the 2600 using an all-new display kernel. The kernel displays a 16x16 grid of squares that can be black, orange, pink, yellow, or cyan, dark blue, or dark green. It can also display a red or brown cursor.
To use the program, load the executable in your favorite cartridge or emulator. On startup, the drawing space will be preloaded with a demo picture and the cursor will blink in the upper-left corner.
Moving the joystick will move the cursor (naturally). Pushing and releasing the button will change the color under the cursor. Pushing and holding the button while moving the joystick will draw with the color under the cursor.
The color/BW switch selects flicker or stripes mode.
The left difficulty switch selects between a brown and red cursor.
Pushing reset will reload the default picture.
Pushing select will cycle colors in the current picture.
Pushing reset and select simultaneously (releasing reset first) will clear the current picture.
The expectation is that this kernel should be good for puzzle games. The whole drawing program is just under 1kbyte.
Note: First attempt was buggy
Second attempt--should be fixed
-
I may have come across as slightly disparaging in earlier posts, but as I view the constraint more as "76 clock cycles" rather than as finite RAM, I see that there's still a lot of challenge left.
One thing I was wondering about: do you show the same colors in the same scan lines every frame, or do you change them? One thing that might work well, if it doesn't expand your engine to the point that it goes kaboom, would be to use interlacing so that you could show colors displaced by 1.5 scan lines each frame. This would allow 2:1 flicker instead of 3:1 and might thus allow for improved appearance.
I do hope to see Boulderdash when it's finished--that was an awesome game though I still can't imagine how a 2600 could pull it off.
-
I'm planning on trying that, actually. My gorgeous title screen idea wouldn't fit in a 1K, though. Maybe I'll have to release my game as a 1K and 8K version. >:*3
-
-
Sound and CPU loading wouldn't affect a Barnstorming time, but it would seem plausible that the game might increase a player's speed as a reward for flying extremely close to a windmil.
-
Combat can be either a good game or a bad game depending upon the skill level and motivation of one's opponent. Without an opponent, it is completely pointless. Even adding a plane variation in which one of the planes flew around rapidly and randomly (but didn't fire) would have allowed some single-player entertainment without much extra programming.
BTW, everyone always seems to think that in biplane-vs-bomber the biplanes have an insane advantage, but somehow when I take bomber I usually do pretty well. Is that just because I can't find good opponents or what?
-
1984 is maybe a bit far back, but I was aiming pre-crash. By 1989, other systems were already starting to take over the market and the Atari was considered 'closeout' material.
BTW, 16K+16K would probably have been a bit much even in 1989. 32K+8K would probably have been more reasonable, though even that would have been a stretch (IIRC, an 8Kx8 RAM would have been about $3, which would turn into $12 retail--and that's just for one chip)
I will grant, though, that I was probably being a little too much of a killjoy though as a programmer who often programs for tiny processors (e.g. 2K instructions and 128 bytes RAM) I tend to admire 'cute' approaches. Perhaps, though, the right way to view things is that the goal on an Atari is not to pack stuff into 4K (or 16K, or 2K) of code space, but rather to pack stuff into 76 cycles. And that's a constraint that doesn't vanish no matter how much memory you throw in.
-
-
ssSnake still sucked big time.Can anyone explain what one is supposed to do in that game?
-
Funny--I was going to mention that game. Actually, though, I should not disparage that cartridge too strongly, since I actually use it a fair amount. The original ROM chip is no longer in it, but unlike many carts this will accept a standard 27C64 EPROM. I no longer have any EPROMs of my first coding efforts; they've been replaced with other game images (I used Harry Dodgson's 7800 cart for some later development).
BTW, Froggo Karate never worked right on my TV. Anyone have a scan-line count for that stupid thing?
-
Search for a program called "22nice". That's a CP/M 2.2 emulator that works pretty well.
-
Any on-the-fly calculations like this wouldn't work, as you'll have to rewrite PF1 and PF2 twice every single scannline...I already took that into consideration. Note that on half the scan lines I do nothing except load a PF register from a temp. The idea would be to arrange the code so that the store would occur at a suitable time. Getting the timing might require adding a few extra register save/restores, but since the X register isn't used for anything it may not, and even if it does there should still be enough cycles to handle it.
The most notable oddity would probably be that the four sets of columns would likely end up not all appearing the same length for any particular 'programmed' length (depending upon where the ror/cpy code was placed). This shouldn't be a problem, though, since the code that sets up the lengths could take that into consideration.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Crazy Balloon Public Relase
in Atari 2600
Posted
Cute game. If you have code space, one thing that might be a nice touch would be to have two death scenes:
-1- If the balloon touches the wall, use the explosion as-is
-2- If the string touches the wall, have the string disappear and force the balloon to rise until it hits something (whereupon the ordinary explosion would occur.
Minor improvement, but such things can help lend polish to a game. If detecting the distinction between a string touch and a balloon touch would be hard, you could force the code to always do death-scene #2 starting with the balloon in its present position. If the balloon itself touched a wall, it would still touch after the string vanished and would pop immediately.
BTW, if you can spare the cycles, a different-colored string might be nice too.