Christopher Tumber

Saturday June 18 Getting rid of a bunch of stuff tomorrow. Nothing scary or rare, just a few boxes of commons and some misc hardware (quite a bit of C64 hardware) - Tradebait that never made it to eBay and I don't have room for anymore. Probably not worth driving out from the city but if you're in the area might be worth a look. Also: 500+ paperbacks (mostly science fiction/fantasy) Board games Household items Perenials

Hey guys, long time no, &etc... So I have a move coming up in the spring and I'm going through trying to lighten the load. Turns out I have a handful of Space Instigators cartridges still. I have 3 copies of the regular edition of Space Instigators for $20 each and 4 copies of the signed and numbered collector's edition available for $50 each. The numbers available for the collector's edition are 17, 18, 19, 21, 23, 24, 25, 27-50. AtariAge.com guide entry Screenshots: Cartridge: Box:

Thanks! It's a little tough to be sure given the length of the clip but it looks to me like it's parallax scrolling of the same sort as Ninja Golf and the layers do not overlap.

No doubt true, however, you're just making the consumer repurchase the RAM on every cart which needs it, rather than having him pay for it once in the console. Unless your business model is to make money selling that RAM, it's just dumb (and even then it's a pretty shaky plan). If, with the 5200, we've established 16k as the baseline for RAM. We put 4k into the 7800. This implies that a substantial number of cartridges are going to use RAM (and I know it was a common complaint from 7800 developers that Atari wouldn't spring for cartridge RAM). Since this RAM has a cost, this means that 7800 cartridges with extra RAM are either going to cost more OR Atari is going to have a lower profit margin on them. Loose. Loose. It didn't have to all be SRAM, either, the first 4K could have been SRAM for video use and there could've been some DRAM - Even 4k that could've been dedicated exclusively to program use would have made a big difference. I just can't imagine cutting RAM by 1/4 from one generation to another - Can you imagine the PS2 having 1/4 the RAM of the PSX? Anyway, I don't mean to turn this into a "stupid Atari tricks" thread, there are already plenty of those...

Dunno, still can't get off the first tower (i hated this game 15 years ago and I still hate it now) Nope. The mountains in the background do not scroll. The trees in front of the mountains do scroll, however, the background behind the trees is a solid white. So even if the mountains did scroll, it'd be a really poor example that doesn't really satisfy the criteria. The underwater levels do have backgrounds that scroll at different rates, however there are no overlapping layers. Fatal Run is like Choplifter. There are large objects (in this case trees) which scroll at a different rate than the background however they are nowhere near the entire width of the screen (moving an object in front of a background is no big deal, every game does that, the hard part is moving and entire screen's width of background in front of another background). In addition, there's scrolling like in the underwate Ninja Golf screens, but again, there's no overlapping layers. I probably didn't state things clearly originally, I'm looking for multi-layered parallax scrolling where the foreground scroll is superimposed on the background scroll on the same scanlines (actually, a scroll over a stationary but complex background [ie: not blank lines like Ninja Golf] would be close enough since it implies the same problems). I still don't think this has been done yet, outside my demo, which only runs on MESS anyway. So it really hasn't been done at all... An example would be Ghouls 'n Ghosts (arcade) (not Ghosts 'n Goblins - the sequel) where the foreground (which you walk on) scrolls in front of a complex background, which also scrolls. The foreground overlaps the background on numerous scanlines.

Thanks Mitch! Guess it's back to ye olde drawing board for me...

Really? So it worked? Awesome! And here you guys had me convinced I'd wasted the week-end... Just to doublecheck, this is a screenshot: If there's problems, they would be a the top and bottom, the red floor and ceiling....

Well that sucks! No wonder nobody's done anything with this hunk of junk (And wtf is up with 4K? Such a huge step back from the 5200! Huh?) Did you actually try it, BJK7382? Did it work? (BTW - You just needed to rename the file) Can somebody break this down for me? My DLL is in RAM. My Display List is in RAM. My list of character offsets is in RAM. My character bitmaps are in ROM. How many cycles *per character*? (I'll just assume 25 cycles of overhead) I'm currently writing 24 characters per line, 8 times for a total of 128 characters (8 headers). The above information gives me somewhere between 256 and 1152 cycles.. Would it helped if I used 2-byte characters? If so, how since writing/not writing to character Character Width doesn't seem to make any difference. What is mean't by Direct, Indirect/1 byte, Indirect/2 byte? Sprite vs character vs 2 byte character? Plus 3 cycles for character map access - I assume per character? So character is 3 times slower than sprite? FWIW when I original did the overlay, I had smaller character lists with more headers and MESS *did* exhibit problems displaying items later in the lists.

Well, the 7800 has two bitmap modes - sprite and character. Really, to my mind "character" is just old school for "tile". The difference is pretty trivial. (tile based systems generally include (bios) routines for handling large maps (etc) obviously older systems have none of that but there's no reason you couldn't add that kind of high level handling yourself, if needed.) My scrollers are in character/tile mode. The fun part comes in integrating the relatively regimented characters/tiles with the much more free moving sprites... I don't see any reason why not.

I have a little multi-colour bitmap editor (currently 140x40 with 9 colours) that saves to a simple binary file. I'm then writing bitmapTo7800 utilities on a case by case basis. Right now I have a utility that converts the bitmap to 320x2 character set data. I'll probably do a sprite converter next. I should probbaly be doing PCX or GIF converters but I didn't have any libs handy. Whatever... 9 colours because I'm not at all interested in the low rez modes and that's the most a can see a 320x2 sprite using resonably (with multi-sprite overlays, obviously). It's all horribly non-user friendly, of course (currently all options must be set in source code, etc) The 7800 made me cry... No idea. I did find that when I was relocating pointers/data that sometimes things would just stop working. So I'd go back, get it working again, relocate all over and it'd be fine. Seems very touchy at times (likely page boundry issues, I'm sure)...

I dunno, frankly I've never gotten past the first level I'll give it another go... Thanks, this started out with the idea that a general purpose tile based background and sprite handling kernal would be relatively straightforeward and really usefull. Well, at least I got the "usefull" part right...

Thanks, but I'm a long way away from a title screen... FWIW, I've been working on some tools as well, these wierd 7800 bitmap modes are just impossible to edit by hand! Looks like you just need to fix the palettes?

- Left/Right Up/Down controls speed. - This is really little more than a "proof of concept" right now - It's a tile-based, reasonably smooth, parallax scroller. The "foreground" and "background" overlap (unfortunately the graphics I've chosen don't really show that off well but if you look closely you'll see) and scroll at different rates. I still need to get sprites working over top of it at which point it should become a nice little display engine. - I'm not well versed in the 7800 library, do any existing 7800 games have a parallax scroll or is this a first? - Choplifter kinda fakes it but it's not really a true overlapping parallax scroll. - While I've borrowed graphics from an existing game, it's is NOT my intention to port that game. I just needed some graphics and didn't want to spend time drawing them. (It's actually a lot more work adapting graphics than drawing new ones, but whatever...) - The left edge of the screen should probably be masked. I'll get to it. - The scroll is a 2 pixel scroll due to the graphics mode (320x2). It would be possible to make a single pixel scroll, however it would be a huge, huge pain in the butt and require a large chunk of ROM which I don't think is justified (IMHO the scroll looks good as long as it's fast enough). 7800kern.zip

This question is basically unanswerable, and not really relevant for Vectrex development. (I'm sure I once posted a RGV some theory on maximums but I can't find it right now. If you want to go searching Google Groups, you might be able to turn it up). The number of vectors that can be displayed PER FRAME (per second is really, really irrelevant) is dependant on a number of factors: 1) Game calcs - Since all game related calculations must be done while drawing and/or between drawing frames the amount of CPU time taken up by calculations will limit the amount of time that can be spent on drawing - ie: A game which requires 50% of CPU for game calcs won't be able to draw as complex a screen as a game which uses 25% of CPU time for calcs. Or one which uses 0% of CPU time (a static image, or a game which uses the trick from VFrogger to do calcs during wait-states while drawing) 2) Optimisation of scale - The Vectrex uses a scale (actually a timer) along with a vector length in drawing. For example, a vector of (0,10) at a scale of 2 is theoretically equivalent to a vector of (0,20) at a scale of 1 (In reality this isn't quite true, there's some "rounding error"). However the vector drawn at a scale of 1 will be drawn in half the time. So obviously the ideal would be to always use a scale of 1. However that's not possible since the maximum vector length is (127,127). At a scale of 63 (very standard) a vector of (0,127) is a little less than half the screen in length. So a variety of scales are used and ideally you want to optimise this (use the smallest scale) but that's often not possible, particularly "on the fly" (especially because of the rounding problems when changing scales). So generally speaking, longer vectors take longer to draw, and for a complex scene the length of time it will take to draw it becomes very complex to calculate. 3) Sequence of vectors - Drawing an object on the screen generally involves moving the "pen" (electron gun) to the starting position of the object, drawing the object, and the re-centering the "pen". Since that initial position of the "pen" and its centering takes some time its slightly more efficient to draw a more complex object. That is, it probably takes about the same time to draw 3 objects with 5 vectors each as it does to draw 2 objects with 9 vectors (with all vectors the same scale) - The latter will appear to be a more complex scene (18 vectors drawn vs 15 vextors drawn). Obviously the most efficient option is to draw as much as possible at one shot (between re-centering the pen) and you can do this by by positioning all objects relative to each other. However, it makes your game code much more complicated and there's also the problem of drift - You can only draw so much between centerings before you start to get drift and eventually the drawing gets completely out of whack. 4) frame rate and brightness - How flickery do you want it to be? The lower the frame rate, the more time you have to draw your scene. Below 20fps you'll start to get flicker. However, it depends - A brighter scene will tend to look less flickery than a darker scene (persistance of vision + the phosphors probably take a litle longer to fade). Essentially, the questiong you've just asked is "What's the best new car on the market". Well, it depends - Do you want to go fast? Do you want to pick up chicks? Do you want to haul cargo?

I'm still around, more or less, just really busy lately. Chris S has been gone for quite a while and I'm pretty sure his interests have shifted elsewhere. My site's been down for a while, my hosting company turned in a bunch of #$&^! and I haven't had a chance to go shopping for a new one. You really should post to rec.games.vectrex on Usenet (use Google groups if you have too).

Okay, so where do you draw the line? What laws do we no longer enforce? Presumably you're also against meter-maids ticketing illegally parked cars - They should be out catching rapists after all! And cops should no longer stop speeders, because there's certainly a murderer they could be hunting down! And thieves, we can forget police going after thieves, because there's still some pedophile priests on the loose! Muggers too, because being a mugger is nowehere near as bad as a murderer, rapist or priest. We won't bother with bank robbers, either, at least not until they kill someone. Because as long as there's even 1 murderer, rapist or pedophile priest still out on the streets cops should be way to busy to deal with anything else!

As mentioned previously in this thread, copyright protection is automatically asigned at the time of creation. It's *possible* that the original owners of Thrust could convince a court to assign them the rights to Thomas' game to them based upon it being a derivative work. However until that happens (and it's not a given - far as I'm aware, nobody knows the legal status of the orginal Thrust game. Presumably the trademark has lapsed [The USPTO doesn't show any video game relted patents, alive or dead] and who knows who, if anyone, owns the rights to the original game) the rights belong to Thomas. Period, end of story. The reason why nobody sues Hozer is that lawyers actually expect to get paid. Hozer is almost certainly "judgement proof" (no assets that could be seized to cover a judgement) even if you could get a judge to award a non-trivial amount. "The defendant sold 20 copies, costing the plaintif $5 a copy. Judgement for the plaintif $100". Legal fees, $2000... However, the US government is busy trying to up the ante as far as criminal prosecution of pirates. Now certainly getting a DA interested in something like this is a whole 'nother kettle of fish, but if I was someone like Randy, that's where I'd start getting worried... Bubba doesn't care if you're Christian.

Read the 2600 Programming For Newbies forum.

I'm afraid you need to be a lot more specific. You've essentially just said the equivalent of: "I'm trying to learn to speak English. I need help getting the grammar right and how to select the correct verbs. Also I need help with my vocabulary" That's way too vague a request for anyone to help you. If you can post specific questions or problems people will be more than happy to lend a hand. Chris...

It sounds like you're talking about modern videogames (PS2, Xbox, PC, etc) if so, go here: http://www.igdn.org/ If not you might want to hop over to the 2600 Programming For Newbies forum.

>I want to stop the dark brown stripes about half way down the screen. I >don't really know where to go from here though? Any suggestions? >Thanks What does this section of code do? ldx #0 Ground inx sta WSYNC cpx #110 bne Ground Chris...

The Adventures of Tron title screen doesn't use anywhere near 128 colours at once. (56 total; 48 in the horizontal bands, 8 in the lettering). You could probably work up a similar looking effect, but 15 colours per scanline is approaching the maximum. Chris...

Well, this is one of those questions like what's the 2600's resolution? Is it 160x192 or 40x192 or something in between... You could squeeze a couple more colours in there, but it's largely just proof of concept and increasingly difficult to be able to do anything actually usefull with the result. For example, the demo I've attached does 15 colours per scanline (no screenshot this time, run the .bin if interested) and that's probably pretty much it, but actually making good use of this capability is another matter entirely... It wasn't so much the number of colour changes per scanline, as how close the colour changes were to each other and how arbitrary the colour changes were (as opposed to completely static colours as in my little demo) Chris... colours.zip

I'd really suggest going with whatever system you like the most. There's enough documentation available for any of the major consoles/computers to get you going. And while the 2600 is pretty unforgiving you actually may be better off starting with it if that's your end goal since you'll avoid any "bad habits" or any over reliance on BIOS/graphic chip type crutches from other systems. In the same way that learning a high level language and then assembly is not neccessarily the best way to go since you have to "unlearn" all kinds of high level habits. In addition, a lot of people never get past the beginner stage. Working on a system you truly love is only going to help get you over the humps - Why spend 6 months or a year working with a system you're not really interested in, just so you can eventually get to the one you DO want to work with? And in the end, worst case, if you do wind up dropping it, you'd probbaly be a lot happier having some "Hello Worlds" and similar type "demos" for the system you really like than some system you were just working with because we told you to. Myself, I learned assembly, back in the day, on Apple II's and quickly moved to the C64. The C64 does have the advantage of very straightforeward video hardware and copious documentation. But again, if you don't care abpout the C64 and you're in love with something else. Go with your love... If you do decide to start with the C64 with an eye to moving to the 2600, pay particular attention to raster interrupts, since the Atari 2600 video output is essentially like one big full screen raster interrupt... BTW - Motorola CPU's of that era tend to be very similar and the transition is pretty easy between them. For example the 6809 (Vectrex, CoCo) is very similar to 6502 with some extra registers and a bunch of new instructions. To the extent where I'd expect 6502 source code to assemble and run virtually unmodified on a 6809 (hrm, that's an interesting thought, that..) Chris...