Tile based Scrolling and expanding Engines

[Thomas Jentzsch]

How do you get around these limitations modifying your large play area in BoulderDash - RAM beyond SARA like the SuperCharger?

Yes, quite a lot of RAM. Our approach is much different to yours.

 

The whole "board" is stored and manipulated in RAM. Plus we have a display buffer, which holds a window of the board, with the board characters (tiles) converted into display graphics. From there we feed the kernel.

[Mr SQL]

fixed it! Please try this build

SCROLLOUT.BIN

That one works without flaws.

 

But I am a person which is pretty sensitive to flicker. Therefore I don't think I could play a game based on this technology very long.

Tom,

I wonder if perhaps the flicker is worse with PAL's 262 scanline mode than on an NTSC television?

 

On my set the shimmer seems to be a pleasing effect, somewhat mesmerising with the large virtual pixels

 

I wouldn't want to play a game with the retro pixels breaking like was happening in the emulator; I wonder if the shimmer effect may be more pronounced when you view it on PAL - does an NTSC signal look different in general on PAL 262 than on an NTSC set?

[Thomas Jentzsch]

I wouldn't want to play a game with the retro pixels breaking like was happening in the emulator; I wonder if the shimmer effect may be more pronounced when you view it on PAL - does an NTSC signal look different in general on PAL 262 than on an NTSC set?

It looks much better than in Stella, but still not acceptable for me. And I doubt the signal will look any different on PAL and NTSC sets.

 

Probably its just my personal flicker sensitivity...

[Mr SQL]

Flickering is really annoying. I've done my own studies and found I can only tolerate a couple of blocks worth of flicker. The engine itself is awesome though! I keep getting fevered visions of a 4 way scrolling Dark Chambers

Thanks loon, I've had a lot of fun building these engines!

There are similar routines in them to the ones in the project you are working on!

 

Four way scrolling Dark Chambers would be awesome

[Mr SQL]

How do you get around these limitations modifying your large play area in BoulderDash - RAM beyond SARA like the SuperCharger?

Yes, quite a lot of RAM. Our approach is much different to yours.

 

The whole "board" is stored and manipulated in RAM. Plus we have a display buffer, which holds a window of the board, with the board characters (tiles) converted into display graphics. From there we feed the kernel.

 

Tom,

yes I was thinking you would have to do another pass over your tiles to build the characters; this pass looks like quite a bit of overhead, are you using precalcuations to optimise this too with lookup tables and such?

 

Can you explain in more detail how you perform these passes to manipulate the data in RAM and render the virtual world to the display buffer? Just concept details of how your engines interact

[Thomas Jentzsch]

yes I was thinking you would have to do another pass over your tiles to build the characters; this pass looks like quite a bit of overhead, are you using precalcuations to optimise this too with lookup tables and such?

 

Can you explain in more detail how you perform these passes to manipulate the data in RAM and render the virtual world to the display buffer? Just concept details of how your engines interact

Andrew has explained that in detail in another thread a few days ago.

 

The key is, that we only do a delta update of the display buffer. So if the character is unchanged, notthing has to be updated. We have highly optimized, dedicated routines for PF0 and PF1/2 (half or full update) buffer manipulation, which run in RAM using selfmodfying code.

 

Also our engine doesn't have to run in sync with the screen display. Instead we have split everything into smaller tasks which are executed from a central scheduler. The highest CPU load happens when a lot of visible tiles change at the same time (e.g. diagonal scrolling or amoeba animation). So the game runs at (slightly) variable speed.

[Sprybug]

Looks good!

 

To enable phosphor in stella, hit alt-p. That said, phosphor in stella is a lot more forgiving that actual phosphors in a CRT.

I just tried that on my super mario demo and the level intro screen looks tons better (without flicker) with it!

I wonder how well it'd run on a real 2600. I think it's time I get a Harmony Cart...

[Mr SQL]

sprybug,

I'm guessing you have the openGL drivers? I only go with the default build because unfortunately that's what most have and alt-p helps a bit but mostly seems to just blur out the pixels as they break rank - can't wait for the next release from stephena with default double buffering (no extra drivers to install).

 

Yes you definitely need a Harmony, highly recommend

 

Excellent Mario demo btw!

 

Tom,

how come bd looks so good scrolling horizontally in the default stella build (without OpenGL)? I don't see the pixels break rank at all!

Edited August 26, 2012 by Mr SQL

[Mr SQL]

SCROLLOUT.BIN

 

Got caught up making a hotfix build for Breakanoid on less forgiving monitors, but here is the next build of Scrollout:

 

I've added a camera to follow the ball after the initial horizontal and diagonal scrolling.

Adding a paddle (on either side) and some randomization is next and the game is ready for play

 

Do not try to watch this one on stella without openGL if you are using windows (hurts a bit).

[+stephena]

I think there's a bit of confusion wrt OpenGL and Stella. Let me clarify:

1. The 4.0 release of Stella will default to double-buffered, hardware accelerated video output using the best option available on the respective OS. That generally means Direct3D for Windows, OpenGL for OSX and Linux, OpenGLES for smartphones/tablets, etc. However, I can almost guarantee that it won't be ready for at least another 3 months, since the underlying library that will make this happen is still in beta and hasn't been released yet.
   
2. There is no 'default' build of Stella without OpenGL rendering installed. All versions of Stella released (by me) include both options. You just need to go into the 'Video Settings' menu and select the renderer to use, then restart the app.
   
3. Just because Stella 4.0 will offer Direct3D support later is no reason to wait for it. All you need to do is install OpenGL drivers for your video card (usually from the manufacturers website), select the OpenGL renderer in Stella, and away you go. While OpenGL might not be as well supported in Windows as Direct3D, either are miles better than software rendering.
   

Long story short: don't feel you have to wait until Stella 4.0 to get tear-free video output. Installing OpenGL drivers is a 10 minute operation and only needs to be done once. Then change the renderer in Stella to OpenGL (and turn on v'sync), and you'll basically have what will be available in 4.0 anyhow. Not to mention that using OpenGL mode gives access to the Blargg TV effects. If your hardware can support OpenGL (all computers released in the last 3 years at least), it's silly not to use it.

[Mr SQL]

 

stephena,

I understand your perspective and I'm on your side like Dr Walter Gibbs

 

User requests are what computers are for!

 

Unfortunately as you've pointed out, Microsoft is a bit like Dillinger in this regard:

 

DOING OUR BUSINESS is what computers are for!

 

And no one installs OpenGL on their own except for a handful of power users and a few wishfull Engineers hoping everyone's a power user. Simply because they've made it very hard; I want the environment 99% of the users have on that platform (most probably your largest distribution platform). That is the default - no OpenGL, no double buffering:

 

Clu, we don't have much time to find that file.

 

I'm not being silly, that is a good reason for me not to install OpenGL. Based on Tom's comments I imagine he hasn't installed OpenGL for that same reason; we need to see what the users will see:

 

If the Users can no longer help us, we're lost.

 

I'm looking forward to the next release because the defaults change and everyone on that version will have it. The problem will still persist for some time though because most users will be on the last version:

 

On the other side of the screen, it all looks so easy.

 

It's tough getting people to upgrade when stella already works so well; even a year after the new release all we can do is encourage:

 

This is the key to a new order. This code disk means freedom.

[Thomas Jentzsch]

Tom,

how come bd looks so good scrolling horizontally in the default stella build (without OpenGL)? I don't see the pixels break rank at all!

Nothing special here. Maybe because we scroll tile based instead of pixel by pixel?

[+stephena]

I agree that if you're a developer and your main focus is to 'get in the users shoes' and see exactly what they see, then it's probably best to not use OpenGL (since many/most? people won't). But if you're simply an end user only concerned with getting the best possible output on your own system, then I stand by my word that you should use OpenGL in Stella. You're only punishing yourself otherwise.

 

I also look forward to the time when all of this is moot: you install Stella and it just works, quickly and efficiently without any extra work on the end-user. I've been trying to kill software mode for years, because honestly it makes emulation look like crap (and brings multi-gigahertz machines to their knees). Unfortunately, this is all most people see when they fire up the emulator, and I feel it leaves a bad taste in their mouth for emulation in general.