Christopher Tumber

Hmm... Is it not supposed to? I just tried the arcade version on emulator and I got UFOs without ever firing a shot... I'm not sure where I copied this from anymore, but these are the notes I have as far as UFO behaviour from when I was fixing the UFO. Th one thing I now notice I haven't done is preventing the UFO from appearing before the first row descends. Which would be a really simple flag if I had either RAM or ROM space available Put it on the todo list since I need to find ROM space anyway and I probably have an available bitflag somewhere. (I don't remember how I determine when the UFO shows up may or may not be every 20 seconds) ;To the UFO show in arcade, the invaders need to be below the first row in the first wave. I mean, in the first wave, the program will wait for the invaders go down a ;row before starting computing the UFO. For the next waves, they already start below this row. ;After that, the UFO will show every 600 frames, supposing you have a 30 frames per second frame rate (it leads to 20 seconds)… ; ;About the correct UFO velocity, enough to say the arcade moves just a game object per frame, beside the invaders themselves. So you have your base, base shot, 3 invaders ;shots and the UFO… The UFO increment is 2 pixels every move and the side it will show (right or left) will be randomly decided. ; ;Here is the ordered UFO score table. It is a circular list, and the pointer moves every shot you fire. ; ;100,050,050,100,150,100,100,050,300,100,100,100,050,150,100,050 ; ; ;The flying saucer’s direction is linked to the player’s shot count. The lowest bit of the count determines which side of the screen the saucer comes from. ;If the saucer appears after an even number of player shots then it comes from the right. After an odd number it comes from the left. ;The saucer object structure is re-initialized every time the player’s shot blows up. Here is the code in Object 1 (player fire):

Thanks guys both these look super-helpful!

I did attach the .bin to the original post. Let's try again... Sp20th.bin

(I know 20 years - WTF?!?) ;Updates since original release: ; Slow down UFO ; Use UFO score table from arcade version ; Make UFO start position based on shot count ; Aliens drop one row lower ; Title screen with settings menu ; Implement Sound setting in game ; Implement NTSC/PAL colour settings in game ; 20th anniversary logo ;To Do ; Improve Shot Display (less flicker) (may not be possible) ; Optional Multicolour Instigators (Non-trivial - need to free ROM space or expand to another bank) ; Ensure smooth transition between Title Screen and Game Screen (no roll caused by too few or too many scanlines) ; Verify UFO scoring is correct (shot counting) ; Verify stable scanlines during game Note: Demo version, requires hard reset after each game.

I'm using developer settings to show scanlines in real time, however it can be difficult to pay attention to both the information overlay and whatever is happening onscreen (ie; if interacting with game to test collision detection) I'm also setting a breakpoint using breakIf _scan==#263 to flag if the screen ever exceeds 262 scanlines but this won't trap cases where the screen is below 262 scanlines. Is there a way to make it really obvious in Stella that there's been a scanline issue? Doesn't necessarily need to be a breakpoint (the problem likely occurred well before the bottom of the screen anyhow). Could be a flash or a pause in emulation. Just something to make it obvious. I may be approaching this completely ass backwards so if anyone has strong methodology for testing picture stability that isn't "run it on a real TV and watch for roll" please share.

Thanks! So for anyone reading this later, my approach will be: Supporting 60HZ (262 scanlines one) only (good side effect of eliminating the supplemental decision of whether or not to adjust game timing) Adding a config/settings menus item to select between NTSC, PAL and SECAM (because why not?) colours From a practical standpoint, this means that something like: LDA #$24 ;2 cycles - Red STA COLUPF ;3 cycles - Set playfield to red Becomes: LDA PlayfiedlColour ;3 cycles - PlayfieldColur is a RAM variable STA COLUPF ;3 cycles - Set playfield to red Or if RAM is at a premium (or just lots of different colour elements): LDX ColourSetting ;3 cycles - ColourSetting is a RAM variable 0=NTSC 1=PAL 3=SECAM LDA PlayfiedlColour,x ;4 cycles - PlayfieldColur is a ROM table STA COLUPF ;3 cycles - Set playfield to red Or possibly more complex logic and tables or temporary buffers - especially if cycle timing is a priority (colour changes during scanlines)

I'd like to start integrating NTSC/PAL switching support directly in my games (as opposed to two separate binaries which IMO is a bigger PITA). Specifically, the ability to switch between 262 and 312 scanlines (60Hz vs 50Hz) NTSC vs PAL colour palettes The most obvious approaches would be either: A menu item (could be problematic if screen is rolling due to incorrect scanlines) Using the consoles switches (Difficulty, Colour/B&W, Game Select, Game Reset) Additionally, about 20 years ago Eckhard Stolberg told me: >There is no need for this. Most PAL TVs can handle 60 Hz VCS output >quite nicely. The picture will be vertically centered with black >bars above and below. It's only important that you do 3 uninterrupted >scanlines of VSYNC. And it would be better, if you'd turn on VBLANK >after the last line of display to make sure that the black bars really >are black. So it seems like offering scanlines and colour palette selection independently might be a good idea. Before I go and do something off the wall - Has there been any standard established here?

Keep in mind that depending on how movement is handled, especially for sub-pixel movement (where your object moves less than one pixel per frame) you don't need to do full collision detection every frame. For example, if the player only moves every 4th frame: Frame 1 - Player Moves - Check collision with 1st quarter of background maze Frame 2 - Player doesn't move - Check collision with 2nd quarter of background maze Frame 3 - Player doesn't move - Check collision with 3rd quarter of background maze Frame 4 - Player doesn't move - Check collision with 4th quarter of background maze Frame 5 - Player Moves - Check collision with 1st quarter of background maze Additionally, you only need to check for collision against objects that are actually near the player. This is particularly useful with a static background (like a Pac-Man maze) since you can optimize this as much as needed but even with more fluid backgrounds (scrolling background) or background objects (enemy ships and bullets) it may make sense to sort or pre-parse objects so you only do collision detection against relevant ones. For example: If player is in top, left quarter of screen only do collision detection against walls in the top, left quarter of screen If player is in top, right quarter of screen only do collision detection against walls in the top, right quarter of screen If player is in bottom, left quarter of screen only do collision detection against walls in the bottom, left quarter of screen If player is in bottom, right quarter of screen only do collision detection against walls in the bottom, right quarter of screen Then you need to have four groups of bounding boxes for walls in each of those four quadrants of the screen rather than just an unsorted list of bounding boxes. You also need a bit of overhead to determine what quarter (or smaller) section of the screen the player is in so your code can determine which set of bounding boxes to use but that's usually a very quick and simple check that may result in a huge payoff by reducing the number of collision detections you need to do by 1/4 (or more)

IMO you're approaching this backwards. regardless of which system you choose to dev for, you have a lot of hours of learning and work ahead of you. Picking the "easiest" system just means X/2 hours instead of X hours. But that's irrelevant if it's not a project you're going to enjoy putting potentially hundreds of hours into. As an example, I personally love the Virtual Boy, however, a lot of people hatehatehate it. Suppose you're one of those people. So what if everyone in this thread came to the agreement that Virtual Boy is the easiest to program for. What would you do? Instead of "what's easiest" I suggest you ask yourself: What is your favorite system or system(s)? What project specifically do you want to develop? (ie; a clone or an original concept?) Which of your favorite system(s) lends itself best to this project? (ie; if a clone, does one already exists on some systems? if an original concept what are the technical requirements?) What are the production issues related to your prospective systems? Some systems are a lot easier to produce physical cartridges, or have them manufactured entirely for you. Or so you want to design your own PCBs, possibly with custom features? Don't overlook production, unless you're going downloadable ROM only these have the potential to put your project on the shelf until resolved. The hobby is littered with dozens of unfinished projects. Unless you absolutely love what you are working on, it's highly likely you will be another one of these. While the learning curve on most systems is considerable that's going to be the case regardless and it's just a matter of degrees. So IMO it's much better to take on a slightly more ambitious project that you're enthusiastic about than an "easy" project that you're going to loose interest in half way through. If you're going to compromise in order to ensure an attainable project, compromise on game details (ie; don't try to push the envelope technically, don't design 75 fully animated sprites to populate 50 highly detailed levels) rather than the core.

Why is it appropriate for other people to do your work for you? Because you downloaded it from an EMU ROM site (or Torrent derivative) like Zophar's or something who, along with ROM checkers like clrmamepro have been misplabelling homebrews for at least 15 years. The "funny" part is that's exactly what people selling ROM CDs on eBay for $20 would say when I'd have eBay shut them down. Le plus ça change. No. Not that it matters. Shareware isn't public domain either.

No, absolutely not.

Everyone hitting F5 waiting for the fireworks...

Then I would like to offer you, and everyone else who follows with similar projects - as this is a recurring issue - the following two pieces of advice: 1 - Stop calling things "public domain" which are not. Clarifying the rights, ownership or permissions issues of any works you plan to redistribute is your number one job. The copyright status of the original Vectrex games is not an obscure bit of trivia. Nor are homebrews. 2 - Before announcing, "Hey guys, I'm going to be mass distributing all these works even though I have no idea what I'm doing or any of the provenance. How awesome is that?" Something like, "I'm looking for contact information for Vectrex authors, developers, modders and rights owners for a potential project. Can anyone help?" might raise a few less hackles.

How about spending the effort expanding and organizing the wiki, with links to the applicable developer, modder, &etc sites instead? http://vectrex.wikia.com/wiki/Vectrex_Wiki

And I found a website that says Elvis Presley was behind 9/11. So what? The people running ROM checksum lists and ROM sites don't care. They've been mislabeling stuff as PD, particularly homebrews, since the mid-90's. None of my material is public domain and you do not have permission to redistribute any of it.