PDA

View Full Version : Inconsistent transparent effects on Saturn games....



Curryman123
01-20-2012, 02:53 AM
Why are there games that only use dithering for transparency?
Why are there some games that can accomplish true transparency in some parts and use dithering for others?
I am guessing backgrounds can be rendered transparent and not sprites?

Also I observed something interesting in Layer Section. Check it out:-

http://www.youtube.com/watch?v=MfcNRQx148c

Laziness or hardware limitation?

lumclaw
01-20-2012, 03:05 AM
Unless I'm horribly mistaken (anyone care to elaborate?), Saturn games must use software for transparency, making it in fact a minor inexplicable step backward from SNES. I dunno about PSX.

Kamahl
01-20-2012, 07:49 AM
Actually the transparency capabilities of the Saturn are pretty much those of the SNES.
The PSX does transparencies the same way modern computers and consoles do, it's very good at it.

Sik
01-20-2012, 09:51 AM
Saturn can do transparency on a per-layer basis (each background is a layer, and the framebuffer is its own layer), but it can't render transparent polygons.

Genesis Knight
01-20-2012, 10:26 AM
Unless I'm horribly mistaken (anyone care to elaborate?), Saturn games must use software for transparency, making it in fact a minor inexplicable step backward from SNES. I dunno about PSX.

Saturn DOES have hardware support for transparencies; it just doesn't have hardware support for cumulative transparencies (several layers of transparencies).

Let's just wait until Koolkitty89 should comes in with a 10 page essay for us. :P

Curryman123
01-21-2012, 01:42 AM
Where are you cool kitty?

Anyways looking at burning rangers...they did transparent effects for the explosions, but smoke (I think that's what it was) is still dithered.

It makes no sense to me. So they got both processors to work together for this particular effect, and called it a day when it came to the smoke transparencies?

Sega Saturn does seem like a bitch to develop for.

TrekkiesUnite118
01-21-2012, 01:44 AM
Well, Burning Rangers works in a weird way. Burning Rangers renders all the transparencies for one frame, then renders all the solids the next frame. It's really processing data at around 30-40 fps, but it appears to display at 15-20 fps as a result. If you slow down the footage to frame advance you can see this if I remember correctly.

Kamahl
01-21-2012, 10:39 AM
The transparencies also look weird, not mixing correctly with one another.

Genesis Knight
01-21-2012, 12:57 PM
Referring to the OP's video - do people actually play vertical shmups in tate mode without rotating the monitor?

Black_Tiger
01-21-2012, 03:26 PM
Referring to the OP's video - do people actually play vertical shmups in tate mode without rotating the monitor?

Just lie on your side while playing. ;)

gamevet
01-21-2012, 03:49 PM
Just lie on your side while playing. ;)

I tried that once, it didn't work. It's like watching a movie while laying on the couch, your brain adjusts what you're seeing to the new viewing angle.

Black_Tiger
01-21-2012, 07:58 PM
I tried that once, it didn't work. It's like watching a movie while laying on the couch, your brain adjusts what you're seeing to the new viewing angle.

If you are serious about playing console games in tate mode, just buy a modest sized crt that you are able to comfortable lift and flip, with a side that will keep it stable.

kool kitty89
01-21-2012, 09:26 PM
Actually the transparency capabilities of the Saturn are pretty much those of the SNES.
The PSX does transparencies the same way modern computers and consoles do, it's very good at it.

Saturn can do transparency on a per-layer basis (each background is a layer, and the framebuffer is its own layer), but it can't render transparent polygons.
According to what Chilly Willy informed me of on this subject, the Saturn's VDP1 is perfectly capable of rendering translucent blended flat/scaled/rotated sprites/objects (when in 15-bit RGB direct color mode) very much like what the PSX GPU does (albeit without dithering support).
It can also render tranlucent warped quads, but has the issue of overdraw causing uneven blending (areas where warped textels are drawn multiple times will result in lower opacity in those areas). This too can be avoided by using proper rasterization (assisted by CPU) rather than VDP1's built-in warping functionality.

However, this is only looking at the framebuffer side of things (which is all graphics in the case of PSX/N64 and nearly all later consoles/computers/arcade boards), but VDP2 is where things get problematic.

15-bit direct color mode for the framebuffer only allows per-layer priority (no per pixel priority -let alone per-pixel alpha channel), so only the entire VDP1 layer can be made translucent or opaque over other VDP2 planes. (though VDP2 planes themselves can use priority on a per-tile basis -and I think per-tile translucency too)
Using the paletted framebuffer modes can allow much more freedom for priority (among other things), but prevents using any shading or blending/translucency within the framebuffer itself. (so you have more freedom to make individual pixels/objects translucent -or different priorities- relative to VDP2 BGs, but sprites/quads can't be shaded/lit or blended with other sprites/objects in the framebuffer -and, while using a mix of 15-bit RGB and paletted pixels at the same time could work around some of those issues, it would still mean that all RGB pixels were stuck at single-plane priority while all paletted pixels were unshaded and unblended with other sprites/objects)


Thus, your main options for using translucency are:
-use only VDP1 and avoid the VDP2 issues (and either avoid translucent warped quads entirely, accept the overdraw-related artifacts, or use software rasterization or dithering as necessary) -or the same thing, but using VDP2 layers without any translucent sprites overlapping with VDP2 layers, and with the usual freedom for per-layer/per-tile priority/translucency.

-use VDP1 and VDP2, and rely on dithered VDP1 objects for any/all cases where you need sprites/objects to be translucent over both other framebuffer objects and VDP2 layers. (this is the main reason you see 2D objects using dithered translucenecy effects)
-any cases where framebuffer objects only need to be blended with VDP2 layers (and not shared or blended with any other sprites/objects) paletted framebuffer pixels can be used instead for added freedom for alpha and priority bits.

Kamahl
01-21-2012, 09:48 PM
The blending available to the VDP1 is also only 50/50 blending, not additive or anything. That only works for blending planes in the VDP2.

TVC 15
01-22-2012, 03:47 PM
Why ask this question... are you trolling Sega Saturn fans? :(

How dare you ask the question that all Saturn fans never want to here spoken. DO YOU HAVE NO RESPECT.

LIES LIES LIES THE SATURN CAN DO TRANZSPAZANZY I SAW IT ONCE IN BURNING RANGERS. BADLY.




JK

sheath
01-22-2012, 04:39 PM
Okay, I'll bite. What does 50/50 blending mean and how does it compare to what the PS1 is doing? To me this just means that the Saturn could only make VDP1 graphics 50% transparent, as opposed to scaling the alpha level to whatever percentage.

Kamahl
01-22-2012, 04:53 PM
Okay, I'll bite. What does 50/50 blending mean and how does it compare to what the PS1 is doing? To me this just means that the Saturn could only make VDP1 graphics 50% transparent, as opposed to scaling the alpha level to whatever percentage.
Yes, and that it's always that kind of mixing, no additive blending for example (which is what makes explosions really bright in PS1 games).
Not only that, if you use warped quads (you know, needed for 3d), the writes are doubled, and that causes the color mixing to get messed up. So not even the 50/50 blending works right.

sheath
01-22-2012, 05:02 PM
I think you are talking about there being lines in the transparencies in some early Saturn games. I thought that was just a glitch relatively easily surmounted if the code was optimized. Basically it seems like you are seeing the seams of the transparent polygons as solid.

Kamahl
01-22-2012, 05:11 PM
If the polygon is textured it's far worse than just a line.

TVC 15
01-22-2012, 05:16 PM
Are there any obvious examples of messed up transparencies in commercial titles? Or did most titles just stick to the tried and tested dithered polys?

sheath
01-22-2012, 05:17 PM
Hmm, that's right, the PS1 used pixelated textures on its 3D transparencies too. That was one of the reasons I didn't get all of the talk about the Saturn's dithered transparency until I got S-Video.

Crazyace
01-22-2012, 05:24 PM
That Layer section video is cool - it shows how vdp2 effects are tied into the display generation, making it almost impossible to reproduce the same parrallax effect when rotating by 90 degrees.

Kamahl
01-22-2012, 06:56 PM
That Layer section video is cool - it shows how vdp2 effects are tied into the display generation, making it almost impossible to reproduce the same parrallax effect when rotating by 90 degrees.
Yeah, because it was using linescrolling and stuff to do the effect (like you would on a genesis).
They could however have done the effect via other means without that same limitation.

Sik
01-22-2012, 07:02 PM
Er, stupid question, wasn't that 50% blend mode actually just a checkerboard pattern? (i.e. not real blending at all) At least that's the impression I got from the stuff in the devkit.

Kamahl
01-22-2012, 07:15 PM
Er, stupid question, wasn't that 50% blend mode actually just a checkerboard pattern? (i.e. not real blending at all) At least that's the impression I got from the stuff in the devkit.
Pretty sure it's really a 50% blend mode, you can see it in games like Sonic R.

Silanda
01-22-2012, 09:11 PM
Er, stupid question, wasn't that 50% blend mode actually just a checkerboard pattern? (i.e. not real blending at all) At least that's the impression I got from the stuff in the devkit.

No, VDP 1 has two modes which can be used for transparency. The one you are talking about (which was more commonly used) was mesh mode, and the slow (items take six times longer to render), glitchy, half-transparency mode which averaged the colours of the transparent object and its background was the other.

sheath
01-22-2012, 09:22 PM
Was the half transparent mode glitchy because of early docs/programming mistakes or because of the hardware feature itself?

Kamahl
01-22-2012, 09:24 PM
Was the half transparent mode glitchy because of early docs/programming mistakes or because of the hardware feature itself?
Hardware.

sheath
01-22-2012, 09:30 PM
Okay, in that case I think I have only seen it in Black Dawn (http://www.gamepilgrimage.com/content/black-dawn-comparison). Whatever Sonic R is doing with the 2D shields has no glitches, and neither does the alpha blending fade in or the Emerald level.

http://www.gamepilgrimage.com/sites/default/files/SatvPS12006/BlackdawnSAT000_001.jpg

Kamahl
01-22-2012, 09:37 PM
The alpha effect in the emerald level is actually a VDP2 effect. The shield still have the problem, but it's not very noticeable unless you have a transparent quad on top of another.

sheath
01-22-2012, 09:49 PM
Yeah, I must not have noticed the glitch at all then. Is the Black Dawn cloud pick what we are talking about?

Kamahl
01-22-2012, 09:58 PM
I have no idea what's going on in that Black Dawn pick to be honest, I'm not entirely familiar with the effects of the glitch. I know in Sonic R you can see that the vertices where the transparent trail quads join are blended incorrectly, it's a similar effect to what's in that Black Dawn picture so... maybe.

Silanda
01-22-2012, 10:08 PM
Yeah, I must not have noticed the glitch at all then. Is the Black Dawn cloud pick what we are talking about?

That looks to be what I would expect. It's caused by the Saturn's anti-aliasing feature drawing extra pixels (i.e. copying adjacent pixels) in order to counter aliasing at low resoultion but I'm not 100% sure of the mechanism of the bug. I'm assuming that a pixel that has already undergone the transparency colour calculation is copied into a gap and then the colour calcuation is performed on it again. If that is the case the result should probably be diagonal lines similiar to those in your picture.

sheath
01-22-2012, 10:23 PM
That is what I can't figure about it either. Black Dawn's cloud glitches are only for some frames, in the same way that the PS1's polygon tearing issue is only for some frames.

http://www.gamepilgrimage.com/sites/default/files/SatvPS12006/BlackdawnSAT000_007.jpg

Team Andromeda
01-23-2012, 03:49 AM
Laziness or hardware limitation?

Both really . I really don't know why people get so caught up in the debate. The Saturn had a real hard time at 3D transparent effect over a 3D polygon even in games like Burning Rangers . It had no trouble when polygons are not being used or the trasnparent effect was a 2D plane there are some fantastic transparent effects in Darius Gadien (an amazing showcase really) , Layer Section and Astal for example


they did transparent effects for the explosions,

Most of the transparent effects on the explosions in BR are the VDP II being displayed vertically.

kool kitty89
01-23-2012, 04:38 AM
The blending available to the VDP1 is also only 50/50 blending, not additive or anything. That only works for blending planes in the VDP2.
Is there any support for additive blending effects using textures? (I know there's additive shading/lighting support -in fact, that's the only shading/lighting method supported in hardware . . . hence why lighting/shading effects look a bit off compared to proper multiplicative lighting -the PSX can do both multiplicative and additive lighting/shading iirc, though multiplicative lighting is apparently limited to 16 shades in early models -not that big of a loss for plain 15-bit RGB, but a greater waste for 24-bit dithered interpolation, not sure how far later models went -but 24-bit approximated with dithering would potentially allow 256 shades/light levels)

Kamahl
01-23-2012, 09:50 AM
Is there any support for additive blending effects using textures?
Nope.

TVC 15
01-23-2012, 06:47 PM
Is there any support for additive blending effects using textures? (I know there's additive shading/lighting support -in fact, that's the only shading/lighting method supported in hardware . . . hence why lighting/shading effects look a bit off compared to proper multiplicative lighting -the PSX can do both multiplicative and additive lighting/shading iirc, though multiplicative lighting is apparently limited to 16 shades in early models -not that big of a loss for plain 15-bit RGB, but a greater waste for 24-bit dithered interpolation, not sure how far later models went -but 24-bit approximated with dithering would potentially allow 256 shades/light levels)

Is additive lighting more computationally heavier to pull off well?

kool kitty89
01-23-2012, 07:58 PM
Is additive lighting more computationally heavier to pull off well?
No, additive lighting is MUCH simpler either in software (usually -aside from CPUs with super fast mult/div) or hardware due to addition logic being much simpler than multiplication/division logic (so fast adders take much less chips space and engineering than fast multipliers -or even slow multipliers for that matter).

This is the main reason that both the Jaguar blitter and Saturn VDP1 use additive lighting/blending/averaging alone.
However, additive blending/lighting is mainly good for translucent blending and colored lighting effects, and looks a bit odd when used for normal lighting/shading effects in RGB (just adding/subtracting 1-bit to each RGB channel to go brighter or darker -the problem being that adding results in desaturation towards white while subtracting does the same towards black). The Jaguar doesn't use RGB for normal shading (aside from 24-bit mode), but instead uses the custom CRY colorspace with 8-bits for linear intensity/luminance/brightness and 8 bits for color/hue/saturation. (so both very smooth lighting gradients -256 shades- and no problems with changing saturation/hue)
Some 256 color renderers also allow linear lighting via look-up. (with the palette customized/optimized for that -which is also why Tomb Raider in DOS has better lighting and contrast than the Saturn version)

The PSX GPU supports multiplicative lighting/shading internally, allowing linear lighting/intensity gradients (all RGB colors fading from full intensity linearly down towards black), though it doesn't do that as fast as some other drawing. (flat shaded/filled polygons are more than 2x as fast -in terms of fillrate- as shaded ones iirc -vs the Jaguar which does both just as fast -again, in terms of fillrate not total rasterization, and I'm not sure about the Saturn)


There's also the somewhat separate issue of flexibility/functionality for additive lighting and alpha blending effects in the GPU/VDP/blitter. The PSX supports additive blending/translucency/lighting as well as multiplicative, but I think it has more flexibility over what it's able to do compared to VDP1. (that's more a matter of what drawing commands/features are included than the drawing/computational resources of the chip) And it sounds like the Saturn can't do straight additive blending, just averaging (which is also additive, but divides the results by 2 -truncates 1 bit from each RGB channel before or after adding).
Plain saturation type adding is good for flame/explosion/lens flare effects (where the translucent object/layer's brightness is combined with the BG rather than averaged with it -so the resulting overlapping pixels are brighter than either of the source pixels -unless the source pixels are already maxed out to the brightest possible RGB values)
Lack of an alpha channels limits what sorts of blending you can do on a per-pixel basis, but would still allow reasonable flexibility on a per-polygon/sprite basis. (if the hardware supports the effects)

For comparison, the Jaguar can do full additive RGB blending in 24-bit mode (albeit no alpha channel stuff) including both averaging and adding/saturation effects, but the blitter can't do much of anything in 15-bit RGB. In CRY, on top of the smooth lighting/shading, the blitter can do simple 50/50 averaging for color and luminance, or some limited additive lighting effects by adding Y (8-bit intensity channel) while averaging CR (the 2 4-bit color channels). It's not as flexible as RGB for that, but it's still useful. (and the high res luminance channel has advantages for quality in additive shading/blending too -though color blending is more limited)


One workaround for using only averaging for blending would be to use extra-bright colors in textures for explosion/flare effects to get the brighter additive look. (not as good or flexible as proper additive blending, but decent for some things)

TVC 15
01-29-2012, 09:06 AM
No, additive lighting is MUCH simpler either in software (usually -aside from CPUs with super fast mult/div) or hardware due to addition logic being much simpler than multiplication/division logic (so fast adders take much less chips space and engineering than fast multipliers -or even slow multipliers for that matter).


The SCU DSP would work in favour with Additive lighting since (as it has been discussed on this board) its fastest at add, multiplication and subtraction math but lacks divide instructions. So I guess if you could juggle the Saturn's resources well (no easy task) you could use the SCU DSP primarily for the lighting process, and stick to the SH-2's for the main bulk of 3D Math, transforms etc.

I think if anything the SCU DSP suggests it may have been a residual component from an earlier design, possibly a slower single CPU system, with the DSP doing the bulk of the 3D math, where 2D was still the prominent focus of the system. When the PSX came around, perhaps SEGA's engineers realised the SCU DSP obviously couldn't cut it alone. Of course I'm speaking hypothetically, had the Saturn been as heavily redesigned like its been suggested.

But anyway I've veered off topic, this stuff would be better in the 5th Gen Comparison thread.

kool kitty89
01-30-2012, 03:48 AM
The SCU DSP would work in favour with Additive lighting since (as it has been discussed on this board) its fastest at add, multiplication and subtraction math but lacks divide instructions. So I guess if you could juggle the Saturn's resources well (no easy task) you could use the SCU DSP primarily for the lighting process, and stick to the SH-2's for the main bulk of 3D Math, transforms etc.

I think if anything the SCU DSP suggests it may have been a residual component from an earlier design, possibly a slower single CPU system, with the DSP doing the bulk of the 3D math, where 2D was still the prominent focus of the system. When the PSX came around, perhaps SEGA's engineers realised the SCU DSP obviously couldn't cut it alone. Of course I'm speaking hypothetically, had the Saturn been as heavily redesigned like its been suggested.
I don't really see how the DSP could be really useful for additive shading/blending in a useful manner (at least beyond similarly limited performance CPU software rendering).

You can't really use CPU/DSP grunt to make up for lack of those sorts of features in VDP1 itself (you'd effectively need to bypass the VDP for those functions), so it would remain much slower than if VDP1 did it in hardware and would reqire substantial added CPU/DSP overhead on top of that. (not to mention, even more overhead due to having to unpack and re-pack 5-5-5 RGB pixels since neither the DSP nor CPUs are designed to manipulate on 5-bit boundaries directly)

The math required for additive blending and shading is very simple, but the real overhead comes from memory access and pixel manipulation. (things VDP1 is very fast at, but limited to the fixed set of hardware drawing commands it's designed for)
And it's also not like software rasterized triangles/quads, which could indeed be accelerated by VDP1. (using the VDP to fill solid/shaded/textured lines between points calculated in software)

And in any case, that wouldn't address any of the limits of additive lighting/shading (compared to multiplicative lighting), but just allow more flexible alpha blending effects.



And absolutely none of that would address the VDP1/VDP2/sprite priority and blending limitations either.

TVC 15
01-30-2012, 05:33 AM
I don't really see how the DSP could be really useful for additive shading/blending in a useful manner (at least beyond similarly limited performance CPU software rendering).

You can't really use CPU/DSP grunt to make up for lack of those sorts of features in VDP1 itself (you'd effectively need to bypass the VDP for those functions), so it would remain much slower than if VDP1 did it in hardware and would reqire substantial added CPU/DSP overhead on top of that. (not to mention, even more overhead due to having to unpack and re-pack 5-5-5 RGB pixels since neither the DSP nor CPUs are designed to manipulate on 5-bit boundaries directly)

The math required for additive blending and shading is very simple, but the real overhead comes from memory access and pixel manipulation. (things VDP1 is very fast at, but limited to the fixed set of hardware drawing commands it's designed for)
And it's also not like software rasterized triangles/quads, which could indeed be accelerated by VDP1. (using the VDP to fill solid/shaded/textured lines between points calculated in software)

And in any case, that wouldn't address any of the limits of additive lighting/shading (compared to multiplicative lighting), but just allow more flexible alpha blending effects.



And absolutely none of that would address the VDP1/VDP2/sprite priority and blending limitations either.

HUH? :?

I'm totally confused, I thought it had just been discussed on this board for the past week that the Saturn uses additive lighting, and the PSX multiplicative, all I'm suggesting is moving the lighting process (if any is performed at all) off the SH-2's to the SCU DSP. I'm aware of how limited additive lighting is for blending/alpha etc as discussed, I'm not even suggesting using the SCU DSP as a work around or as a software render outside of what the VDP1 does, I'm merely suggesting using it to perform any additive lighting calculations. Or have I totally misunderstood most of this discussions, and the VDP1 does this sort of math in hardware. Thats why I made the point that this is in the wrong thread, it has nothing to do with transparency inefficiencies on the Saturn... ahem.

Well, I suppose it will at least clarify things. I guess I shouldn't comment on tech when I can't code for shit...

kool kitty89
01-31-2012, 04:22 AM
HUH? :?

I'm totally confused, I thought it had just been discussed on this board for the past week that the Saturn uses additive lighting, and the PSX multiplicative, all I'm suggesting is moving the lighting process (if any is performed at all) off the SH-2's to the SCU DSP. I'm aware of how limited additive lighting is for blending/alpha etc as discussed, I'm not even suggesting using the SCU DSP as a work around or as a software render outside of what the VDP1 does, I'm merely suggesting using it to perform any additive lighting calculations. Or have I totally misunderstood most of this discussions, and the VDP1 does this sort of math in hardware. Thats why I made the point that this is in the wrong thread, it has nothing to do with transparency inefficiencies on the Saturn... ahem.
OK, in that context, your argument makes more sense, but you misunderstood the actual mechanism used for shading/lighting/blending in either console.

All these shading and lighting effects in question (that were recently discussed) are done in hardware by VDP1 and the PSX GPU (additive blending in both cases, and additive shading used for flat/gouraud shading and lighting on the Saturn but multiplicative lighting/shading used on the PSX GPU -and the jaguar using additive on the blitter end, but effectively using linear/multiplicative lighting due to the nature of the CRY colorspace)
The PSX achieves that by having internal multiplication logic to manipulate RGB pixel values when shading, but the Saturn relies on simple addition/subtraction of RGB values instead (which leads to desaturation towards white or black as you push lighter or darker shades -vs constant saturation with multiplicative lighting . . . or constant within the practical limits of 15-bit RGB -you get some rounding/truncation errors).

There's no CPU intervention whatsoever in either case (aside from sending the drawing commands to the VDP/GPU), so there's nothing to offload to the DSP . . . unless you switched to software rendering (which would be MUCH slower than GPU rendering . . . though it's what you have to do on the 32x, or PCs of the time for that matter ;))

Edit:
Hmm, actually, there's more the CPU has to do for actual calculation for light-sourcing and such (to define the actual light levels and shading gradients used in the VDP/GPU drawing commands), but that's not what we were talking about with the additive vs multiplicative shading issue. (that, as above, was in the context of how the GPU/VDP actually shades the pixels -ie takes a given color value and shifts that to the desired shade via math/logic -software renderers often use look-up-tables instead, but achieve analogous resulting effects)
Actual light sourcing is done in software on ALL of these systems (and every system prior to hardware T&L support -and even then it's technically in software too, but offloaded into a GPU program rather than CPU -which the Jaguar technically does too), and all systems of the time would be using relatively similar methods for light-sourcing in software (some more complex than others depending on available CPU resource and the actual need for lighting complexity in a given game), and that's a very different context than the additive vs multiplicative pixel shading dicussion.


Well, I suppose it will at least clarify things. I guess I shouldn't comment on tech when I can't code for shit...
I can't code much myself (yet . . . and nothing at all on any consoles), but I've managed to soak up a decent amount of general technical knowledge to have a decent general grasp on understanding of some of these things.

Plus, a lot of this isn't just stuff to understand from a programming standpoint either, but a hardware design/engineering standpoint. (something I gained insight into by reading various technical documents, articles, and reading -and in some cases partaking in- technical discussions with those with significant engineering experience -or others with a heavy hobby interest in the topic)

Zz Badnusty
07-10-2015, 12:12 AM
This recent video by "Low Score Boy" presents a thorough breakdown of Sega Saturn transparency abilities. The analysis of Burning Rangers makes me wonder how awesome it would be to hear or read remembrances from the Sonic Team programmers (http://segaretro.org/Burning_Rangers#Production_Credits).

f_OchOV_WDg

cleeg
07-10-2015, 04:07 AM
Thanks for sharing, I enjoyed and sort of understood that! I would like to make clear that that isn't a slight on Low score boy's English, rather the technical stuff he was saying.

maxi
07-10-2015, 04:37 PM
I saw this video in sonicretro, it is indeed very good.