Defenderesque StarBlitz

[+SpiceWare]

Like I reported in "that other thread", the flickering is very hefty. That hefty, that I cannot play the game for more than a few minutes.

 

 

Same here. Just tried it on my VCS and that amount of flicker exceeds my tolerance.

 

The screen also jumps up/down on my C= 1084S whenever the ship collides with an object. That's most likely related to the < 3 scanlines of VSYNC that's covered in "that other thread". I'll have to look into improving my jitter routines to make Stella emulate that.

 

Recording of the screen jumps - StarBlitz.m4v (7.66 MB)

[Thomas Jentzsch]

perhaps only you and RevEng can see it to the point it makes the game unplayable for you?

 

Yea, for sure, that must be the reason. (oh, and Darrell, we three must be the exception)

 

Looks like you are not prepared for constructive negative feedback. I quit.

 

BTW: I posted in the other thread that the flicker is hefty under all conditions. There is no hypnotic effect, just way too much flicker.

Edited February 12, 2016 by Thomas Jentzsch

[+SpiceWare]

I had an issue with full screen flickering in e1will's SuperPac demo.

 

Looks just like your screenshot on a real Atari.

 

The flicker is pretty bad though because it's the entire screen flickering. I suggested taking a look at Ladybug which flickers 2 colors for the playfield. It works quite well. Ladybug also uses the right difficulty switch to select between darker or lighter playfield colors. Darker colors don't flicker as much.

[Mr SQL]

 

Yea, for sure, that must be the reason. (oh, and Darrell, we three must be the exception)

 

Looks like you are not prepared for constructive negative feedback. I quit.

 

BTW: I posted in the other thread that the flicker is hefty under all conditions. There is no hypnotic effect, just way too much flicker.

 

Tom don't get sore; you, Darrell and RevEng all have programmer perspectives like I do - let's hear from some gamers who are playing the games.

 

We can start with the German reviewer - you speak German, so you can tell me if he is saying the flicker is quite minimal for an Atari game (which is the opposite perspective) and finds the display captivating, or if he thinks it's unplayable

 

Fine too if you don't want to play

[Mr SQL]

I had an issue with full screen flickering in e1will's SuperPac demo.

 

 

It's full screen animation at 30 FPS Spice, but the entire screen isn't flickering at 30 hz because you can't see the black background, that's why I use black between frames, also phosphor persistence.

 

A Television image updates the same part of the screen only every other frame/30 FPS as well, it's only the active cells of the playfield that can flicker and using colors closer to the left of the color chart mixes them better with the black so the flicker is less perceptible; I actually spent a lot of time optimizing the display. The artifact colors help maintain more phosphor as well on an analog TV - try the game on your Television if you haven't already.

[Mr SQL]

 

 

Same here. Just tried it on my VCS and that amount of flicker exceeds my tolerance.

 

The screen also jumps up/down on my C= 1084S whenever the ship collides with an object. That's most likely related to the < 3 scanlines of VSYNC that's covered in "that other thread". I'll have to look into improving my jitter routines to make Stella emulate that.

 

Recording of the screen jumps - StarBlitz.m4v (7.66 MB)

This is interesting, does the build we tweaked with Tom (on the other thread) fix the display on your monitor?

 

Edit: The game looks awesome on your monitor when the screen is not rolling on the collisions.

I'm surprised 30 hz flicker can seems so excessive to you - to me the game looks solid, I can't even percieve minor flicker. I see plenty of flicker in Wizards of Wor (still great game) and a bit too much flicker in pacman ghosts but still playable and doesn't break the game. Could it be the speed of the animation is part of it? ie, moving too fast? Tom's demo is really fast and difficult to look at.

Edited February 12, 2016 by Mr SQL

[+SpiceWare]

It's full screen animation at 30 FPS Spice, but the entire screen isn't flickering at 30 hz because you can't see the black background, that's why I use black between frames, also phosphor persistence.

The entire screen is flickering because of those black frames. Phosphor persistence isn't a magical cure-all like Stella can make it appear to be (Super Pac-Man looked awesome in Stella). On a real CRT the phosphors decrease in brightness during the black frame. This makes the image brightness increase/decrease/increase/decrease/etc, which is the source of the flicker.

 

A Television image updates the same part of the screen only every other frame/30 FPS as well, it's only the active cells of the playfield that can flicker and using colors closer to the left of the color chart mixes them better with the black so the flicker is less perceptible; I actually spent a lot of time optimizing the display. The artifact colors help maintain more phosphor as well on an analog TV - try the game on your Television if you haven't already.

The C= 1084S is a CRT monitor with the same specs as a TV. In fact, back in the 80s and 90s it was my TV - I used an S-VHS deck as the tuner. The reason phosphor persistence works so well when watching an interlaced TV show is because the scanlines drawn using electron beams and phosphors aren't a consistent size like those of an LCD display. Look closely at the screen the progressive signal of the Atari puts out and you can easily see that the scanlines being drawn are thicker than the scanlines being skipped over:

 

Do to that thickness the scanlines from the even frames will overlap those of the odd frames, and vise versa. That overlap effectively hides any flicker due to phosphor fading.

 

Some people have a higher tolerance threshold for flicker like in StarBlitz, I don't. You can do what you want with your game, but if you release it as is I will never play it because of the flicker.

[+SpiceWare]

This is interesting, does the build we tweaked with Tom (on the other thread) fix the display on your monitor?

The one in reply #44 still jumps.

 

Edit: The game looks awesome on your monitor when the screen is not rolling on the collisions.

I'm surprised 30 hz flicker can seems so excessive to you - to me the game looks solid, I can't even percieve minor flicker. I see plenty of flicker in Wizards of Wor (still great game) and a bit too much flicker in pacman ghosts but still playable and doesn't break the game. Could it be the speed of the animation is part of it? ie, moving too fast? Tom's demo is really fast and difficult to look at.

Camera lens is different than human eye, it can hide flicker. If you look closely at the Harmony menu during the first 2 seconds of the recording you might notice that the bottom half is flickering while the top half isn't.

 

I find the flicker in the Harmony menu to be annoying, but I can tolerate it because I'm only looking at it for a short period of time. Likewise I don't care for the flicker in the Space Rocks or Draconian logos, but they're only onscreen briefly, plus they're not full-screen. For me a few flickering sprites in games is OK, but full screen flicker isn't.

 

I also have trouble with LadyBug, especially the green sections of the maze, though if I reduce the luma value (right difficulty switch) I can tolerate it for a game or two.

[Mr SQL]

The entire screen is flickering because of those black frames. Phosphor persistence isn't a magical cure-all like Stella can make it appear to be (Super Pac-Man looked awesome in Stella). On a real CRT the phosphors decrease in brightness during the black frame. This makes the image brightness increase/decrease/increase/decrease/etc, which is the source of the flicker.

 

 

The C= 1084S is a CRT monitor with the same specs as a TV. In fact, back in the 80s and 90s it was my TV - I used an S-VHS deck as the tuner. The reason phosphor persistence works so well when watching an interlaced TV show is because the scanlines drawn using electron beams and phosphors aren't a consistent size like those of an LCD display. Look closely at the screen the progressive signal of the Atari puts out and you can easily see that the scanlines being drawn are thicker than the scanlines being skipped over:

IMG_6966.jpg

 

Do to that thickness the scanlines from the even frames will overlap those of the odd frames, and vise versa. That overlap effectively hides any flicker due to phosphor fading.

 

Some people have a higher tolerance threshold for flicker like in StarBlitz, I don't. You can do what you want with your game, but if you release it as is I will never play it because of the flicker.

That's unfortunate, I get what you are saying about your threshold but I think you may be on the low tolerance side since 30 hz matches television:

 

Your example is excellent, you understand what I am saying about Atari putting out a progressive scan - it updates the same lines 60 times a second while the NTSC broadcast spec updates half the scanlines on alternate frames and is interlaced. The phosphor actually helps because it maintains the image during the interlace, and that is what my effect is replicating, I am just hitting the same scanlines every other frame instead of half of them, every other frame.

[+SpiceWare]

You're missing the part on how the CRT scanlines are thicker so that the even and odd scanlines overlap. That overlap helps to hide the fading phosphors.

 

Your game doesn't have that overlap, so it doesn't get hidden.

[Mr SQL]

You're missing the part on how the CRT scanlines are thicker so that the even and odd scanlines overlap. That overlap helps to hide the fading phosphors.

 

Your game doesn't have that overlap, so it doesn't get hidden.

hmmm... we understand that part differently.

 

I think the thickness isn't the issue because regardless every scanline on the screen is updated 60 times per second with the Atari but only 30 times per second with the NTSC broadcast signal.

 

So 30 times a second for NTSC Television each scanline is running on nothing but phosphor, just like my rendering engine. IMO the phosphor helps hide the flicker so it's not really black for 1/30th of a second and lit up for 1/30th, there's persistence. With 60 FPS second from the Atari signal we've just got a higher update rate which is what lowers the flicker. Phosphor persistence lowers it further still.

 

My game has the same overlap as NTSC broadcast, could you see the 30 hz flicker watching television on a tube TV?

 

Interesting results on our jitter testing, I will follow up on discussing that part on the other thread if anyone is interested in following along since it may not be vsync.

[RevEng]

A broadcast 480i signal displays fields at 60hz. Your game's 240p display would equivalent to broadcast (sans interlace) only if the broadcast signal drew every other field as black. But no broadcast material does that.

 

The key part of interlace that reduces flicker is that both fields carry similar material. Your game doesn't do that.

[Mr SQL]

A broadcast 480i signal displays fields at 60hz. Your game's 240p display would equivalent to broadcast (sans interlace) only if the broadcast signal drew every other field as black. But no broadcast material does that.

 

The key part of interlace that reduces flicker is that both fields carry similar material. Your game doesn't do that.

 

Excellent point RevEng, but it displays frames at 30 hz so it has to leave the field black - an electron gun does not actually paint anything black so when I paint the field black nothing happens and the effect is the same as leaving it black 30 times per second.

 

Either way the phosphor has 1/30th of a second to power the blank/black scanlines, every one of them on the screen.

 

On a CRT this is close to the NTSC 30 hz only the entire frame is in the same phase whereas NTSC has the two fields out of phase.

 

But interesting point about painting the scanlines black is that LCD and other display technologies don't operate the same way as CRT with black or phosphor.

[RevEng]

Excellent point RevEng, but it displays frames at 30 hz so it has to leave the field black - an electron gun does not actually paint anything black so when I paint the field black nothing happens and the effect is the same as leaving it black 30 times per second.

For broadcast material: One field may be fading as the other is drawn, but it's not black. For one 60Hz period odd lines are drawn. As the top of those odd lines start to fade out, the next 60Hz period begins and very similar even lines are drawn near the fading ones. The similarity and proximity reduces the flicker.

 

For your game: One 60Hz period sees the playfield lines being drawn. As the top of those lines starts to fade, the next 60Hz period sees nothing being drawn.

[+KaeruYojimbo]

I just tried the most recent version in Stella. While I personally don't find the flicker intolerable, it is definitely noticeable. There were actually two things that bothered me more. First, the movement of the enemy sprites is very jerky. Second, the ending of the game is too abrupt. I really feel like something needs to happen between taking the last hit and returning to the title screen.

[Mr SQL]

For broadcast material: One field may be fading as the other is drawn, but it's not black. For one 60Hz period odd lines are drawn. As the top of those odd lines start to fade out, the next 60Hz period begins and very similar even lines are drawn near the fading ones. The similarity and proximity reduces the flicker.

 

For your game: One 60Hz period sees the playfield lines being drawn. As the top of those lines starts to fade, the next 60Hz period sees nothing being drawn.

Great point again RevEng, and also an excellent description why nothing is being painted black on a CRT.

 

The proximity of the lines being drawn by the alternating field reduces the flicker, but both 30 Hz signals are encoded in 60 Hz so that is always true for each scanline - the next 60 Hz period leaves it runnning on nothing but phosphor and nothing is being drawn.

 

You can't get 60 Hz out of a 30 Hz display by running the fields out of phase but you do get a minor boost from the proximity. Phosphor gives us the largest boost (main reason why TV looks better for video games) and maintains considerable illumination for 1/30 of a second.

 

This gets more interesting for Tom with his PAL Television which leaves out many scanlines in StarBltiz that light up on NTSC Televisions to render gorgeous artifact colors and more phosphor.

[Mr SQL]

I just tried the most recent version in Stella. While I personally don't find the flicker intolerable, it is definitely noticeable. There were actually two things that bothered me more. First, the movement of the enemy sprites is very jerky. Second, the ending of the game is too abrupt. I really feel like something needs to happen between taking the last hit and returning to the title screen.

 

Yes the meteors take random pauses falling, I will post a version without this to compare and see if it makes it too easy.

The enemy fighter is pretty smooth I think. How about the movement of the enemy drones? Would you prefer those to move like the players drone?

 

hmmm... Maybe the ship slowly blowing up and the remmnants of the city fading out after the last hit?

[+KaeruYojimbo]

The enemy ship and the enemy drone are fine, it's mainly the meteors that bug me. It feels very odd for a meteor falling to the earth to pause.

 

Having the remaining city fade or crumble away could look very cool.

[Mr SQL]

 

Yea, for sure, that must be the reason. (oh, and Darrell, we three must be the exception)

 

Looks like you are not prepared for constructive negative feedback. I quit.

 

BTW: I posted in the other thread that the flicker is hefty under all conditions. There is no hypnotic effect, just way too much flicker.

 

Tom,

A German college professor emailed me about the German review:

 

He likes the game, explains to readers the need to consider the platform, precisely as Atari 2600 game, and notes that you, the 'Coder' are open to suggestions and friendly when it comes to responses and have posted several different versions, which he thinks is great.

 

I ran the translator from google if anyone wants to check it out, it's a cool review, I like the German expressions and his ideas to add "a couple of enemy fighters" which I think we have:

 

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fnemesiz4ever.de%2Fboard%2Fthread.php%3Fboard%3D24%26thema%3D11&edit-text=&act=url

 

Here's the video you asked for showing how StarBlitz was breaking in Stella on Windows 10 compared to a video where Stella is emulating it perfectly; it's a kind of flicker too but it's not flicker and worse with animation.

 

Stella_difficult_to_look_at.mp4

Stella_looking_good.mp4

 

It's tremendous fun to push the VCS but I I like for people to be able to play my games and it's disappointing to see them breaking - I would have only released a video of StarBlitz, just like I did with KC Munchkin, if I knew it could look horrible like that. That's what Keatah and the indieretronews reviewer saw too; it's not a fair representation of my game.

 

Would you like it if Stella had done that to the Boulder Dash demo, and all other games worked?

[Keatah]

Having played with emulators since the 1990's I know they are not always perfect. But at the same time I also know they can make provisions for games that operate on the fringe. Games near the edge of the envelope. The can provide special handling routines for corner cases and unique games. They can simulate hardware tricks and artifacts. Similar to what MAME "appears" to do - tweak & fix each game on an individual basis.

 

I would tend to believe the developer of Stella needs to make options and modifications to support some of these games. Otherwise, in my eyes, the emulation is incomplete. The emulator has to understand CRT and LCD and make appropriate concessions so that the contemporary choice (LCD right now) will look like it should. After all, if I point my videocamera at StarBlitz or KC Munchkin while running on a CRT and play it back on LCD or YouTube, it looks correct. So the LCD can get it right. No excuses. No longer can emulator developers not consider this.

 

The emulator must have an understanding of the characteristics of contemporary display technologies (LCD and CRT), or else it is incomplete. I would even argue that to deal with the leading-edge dimming problem inherent in LCDs, the emulator should make those pixels overbright for an instant to help them turn on quicker. And the opposite for trailing edge, make them turn off faster to speed the return-to-black. This would need to be adjustable and across the entire color spectrum⁽¹⁾.

 

As time rolls on and hardware ages or becomes less available, emulators (software, hardware repro, FPGA, whatever) are going to become more prevalent. And it's a good thing some devs are considering that.

 

As for the flickering bothering me? It doesn't too much. What kinda-sorta does, and exacerbates it, is the ship flying through the areas of the STARBLITZ text. One instant it is over the writing, then there is a blank spot between letters. I find I need to stop after a while. That's just my opinion. When I play Defender, Gorgon, Repton, Eliminator, Rear Guard, StarBlazer, and Stargate, I find myself always making an effort to fly above any terrain. Here in StarBlitz there is no escape!

 

I also would like to see the reset switch do something, stop the action and "reset" the game.

 

Hope all that made sense! That RetroVGS fiasco has my head scrambled temporarily.

 

 

1- When I retire soon I'd like to begin funding for getting a lot of these display inaccuracies cleared up across many PC-based emulators. I don't think I have the time or patience right now to direct such a project. It will happen someday.

Edited February 14, 2016 by Keatah

[Mr SQL]

Having played with emulators since the 1990's I know they are not always perfect. But at the same time I also know they can make provisions for games that operate on the fringe. Games near the edge of the envelope. The can provide special handling routines for corner cases and unique games. They can simulate hardware tricks and artifacts. Similar to what MAME "appears" to do - tweak & fix each game on an individual basis.

 

I would tend to believe the developer of Stella needs to make options and modifications to support some of these games. Otherwise, in my eyes, the emulation is incomplete. The emulator has to understand CRT and LCD and make appropriate concessions so that the contemporary choice (LCD right now) will look like it should. After all, if I point my videocamera at StarBlitz or KC Munchkin while running on a CRT and play it back on LCD or YouTube, it looks correct. So the LCD can get it right. No excuses. No longer can emulator developers not consider this.

 

 

 

I've added the continuous city and adjusted the meteors for a uniform falling rate.

I'm going to add a couple more of the ideas from this thread, and will release the new version presently along with the source code for developers.

 

StarBlitz has already caused some controversy; this video of the new version running on an unmodified Vader may cause more:

https://youtu.be/IJukQwlaU9s

 

Here's a question for gamers and collectors:

 

Since the game breaks four different ways in Stella and falls apart painfully on some Windows 10 installations, should I make StarBlitz lock up the emulator and only play on the real hardware?

 

I'm asking this question based on the responses on the emulator thread linked above and the science thread; the game still looks good in Stella when the emulator doesn't intermittenly break apart (Windows 10 Pro), but SpiceWare is considering adding code to Stella to make it break StarBlitz in yet a new sixth way and I think this is the wrong direction for emulation.

 

Some developers feel very strongly that the video Spice posted makes StarBlitz "look too good" as it is and pooh-pooh the notion a composite mod breaks the artifact color set; the videos make it easy to compare a composite mod side-by-side with the real (unmodified) hardware.

 

I hope some CoCo programmers or Bill Loguidice can help to exlucidate; it should be possible to create a composite mod for the Atari to maintain or even increase the artifacting rather than removing it but once you've modified the hardware you've got a different machine which shouldn't be used as a model for emulation.

 

Emulation can only catch up if we (programmers) don't make excuses - throwing insults can only result in future versions of the emulator throwing more exceptions when trying to run games that push the hardware.

 

I was playing StarBlitz last night when I made this video and there was so much phosphor it was flowing out of the Television and spilling

over onto the Atari and the table in my workshop, coating the walls with the effervescent incandescence of phosphor in it's plasma state; the high frequency oscillations don't fade away.

 

I hope StarBlitz inspires other programmers to utilize some of these techniques in their games or come up with other cool ideas, it would be awesome to see more smooth horizontal scrollers; indeed the Atari can do it!

 

 

[Keatah]

Since emulation software deals with 2 platforms, it will need to support many options and modes of operation. By that I mean an emulator should always strive to mimic the target hardware as accurately as possible and yet understand the peripherals of the host platform and how they work.

The first and ultimate goal is accuracy. If it breaks user/application software in the process, so be it. As long as it breaks it in the same way the original unmodified hardware does.

This further implies that the emulator is aware of the LCD's characteristics to which it outputs. And that it also understands the differences between it and the native CRT. It is all too easy for the developers of emulators to not go beyond the video chip of the emulated system. But yet game developers sometimes rely on anomalies of the display subsystem to generate effects.

Doing artifacting and relying on idiosyncrasies of the NTSC signal to get pseudo-colors, or using
phosphor persistence to get extra shading, are examples of that. Even v-syncing with the frame rate.

An emulator should also be able to make subtle improvements above and beyond the target hardware. This is a secondary goal. A luxury, an amenity. It may mean macros, multiple clock speeds, auto-fire, extra phosphor delay, a snippet of code to account for annoyances in the original equipment - think external bios'es like for Fast SC Bios loading, or the zero- delay bios in Colecovision. Having an option or replaceable bios fixes the annoyance. Overclocking the original cpu can sometimes lead to desirable results in both games (ballblazer) and applications alike.

3rd, an emulator needs to make concessions for games it cannot handle through its main loop. This has to be done on a game-by-game basis.

Look at these screenshots from Altirra. Without NTSC/CRT/TV artifacting and with. This is a good example of the emulator "understanding" color artifacting of outdated hardware of the day and making concessions. Simulating the effects of playing with the signal.

 

Edited February 17, 2016 by Keatah

[Thomas Jentzsch]

Stella is an emulator, it does not replicate the original system. For doing the latter, you have to replicate the TIA timing bit by bit (and maybe even the various versions). What you are asking for is a complete rewrite of Stella's core. Actually Stephen has been looking around for this for quite some time now. Are you volunteering?

 

And you cannot completely emulate a CRT on a LCD.

 

For me, an emulator is a good approximation of the real hardware.

[Keatah]

Not volunteering. Don't have the time to develop the necessary skill. Eventually I'd like to commission a such a project sometime.

[Mr SQL]

The artifact panel from Altirra looks awesome, it would be really cool to see something like this implemented for Stella.

 

Here are examples of vertical multicolor sprites only possible with artifacting, the plasma effect of the ion shield glow and ordinary unartifacted characters in StarBlitz that would be fantastic to see in the emu:

 

 

I still need to tweak the latest version of StarBlitz but for anyone who want's 5C now the download is on my site along with the real source code:

 

StarBlitz is written completely in BASIC, the techniques are all simple and straight forward

 

There's also an international programming contest linked on my site if anyone wants to write a 10 liner in BASIC; BASIC is a powerful language and medium for prompting creative expression - it's tough to do that in Assembly sometimes, easy to lose continuity because it takes forever.