Giter Club home page Giter Club logo

Comments (16)

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
8 bits also show problems (see #2, although some of it is my fault). 16 bits 
seem to
work fine though.

The game Tantric works on seems to use 16 bit depth (at least the upstream 
source) :-)

Original comment by [email protected] on 29 Apr 2009 at 4:06

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
To add a little info. to this -

I think the issue is in WII_FlipHWSurface() and the calculation:

int rowpitch = (this->hidden->pitch >> 4) * 3;

I think this is specifically for 16bit surfaces.

I know that GX stores the image 4x4 tiles for optimization.  We'd need to find 
and
equation that supports 8,24 and 32bit.  

Original comment by [email protected] on 29 Apr 2009 at 7:54

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
It's more complex than that, but you are on the right spot. I've just committed
partly working (i.e., broken but in a different way!) 8-bit support. Zooming is 
wrong
and the bottom half of the window is missing, but it seems to handle my palettes
quite OK now [1].

With 16-bit being the "native" mode, 32-bit should be possible to implement in a
similar way as 8-bit support. For 8-bit, I lookup pixel values from a palette, 
while
the 32-bit would simply "compress" the 32-bit pixel value into 16-bit RGB565.

There are still stuff I haven't quite understood though :-)

[1] The color blue shows beautifully!

Original comment by [email protected] on 29 Apr 2009 at 8:01

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
OK, I've been looking over this issue and wanted to add support for 24 and 
32bit. 
The way I see it there are two ways to do this.  Please add more ideas if you 
have
them.  

First would be to change the GX texture to GX_TF_RGBA8 for RGB and RGBA 
surfaces. 
Not sure how this would perform or handle if you mix bit depths within your 
program.

Secondly would be to convert RGB/A to 16bit YCbCr.  This would be a big 
performance
hit if you use 24/32bit surfaces as they would need to be converted each blit.

Also is there any reason why 16bit seems to be the native depth of SDL?  I 
noticed
this even in the old port.  Is the Wii's bit depth only 16bit ?



Original comment by [email protected] on 30 Apr 2009 at 4:43

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
8 and 24 work ok. 32 is not written.

Original comment by [email protected] on 14 May 2009 at 5:20

  • Changed state: Started

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
Yes, still needs finishing.  I'll be looking at it some more.  I'm not too 
happy with
the current methodology, you can only load 640x480 surfaces.  Although adding a
memory allocation for each blit would slow things down.

Original comment by [email protected] on 14 May 2009 at 5:29

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
I agree. Keep in mind we could utilize scaling (GX or VI) for smaller/larger 
surface 
sizes. But this still needs to be written...

Original comment by [email protected] on 14 May 2009 at 5:32

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
Some comments from a user's view:

I have been using 8 bit mode and this produced a black screen when compiling 
with the
4-23-2009 version. Changing to 16 bit displayed the images far less clear than 
before
and the game ran slower overall. 

Will the current SDL version work with the next download of devkitpro coming 
up? Is 8
bit mode as clear and fast as before then?

Original comment by [email protected] on 27 Jun 2009 at 1:00

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
I don't believe there has been any changes to 8-bit mode since I hacked up a 
version
that actually works. It's clumsy and non-optimal and the palette is not quite 
what it
should be, but it seems to be at least as fast as the old non-GX one (with my 
tests
in Frodo).

For best performance, you should be using 16-bit depth. I'm surprised that 
16-bit
mode would be slower - from what I've seen it's a lot faster than the old non-GX
implementation. Make sure that you don't have surfaces in 8-bits which needs to 
be
converted for each blit, that could make things slower.

Not much of an answer, I know :-)

Original comment by [email protected] on 28 Jun 2009 at 7:27

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
He is referring to the 4-23-2009 version, which I believe is the pre-GX SDL. 
Yes, a 
new SDL will be released immediately following the devkitpro release.

Original comment by [email protected] on 28 Jun 2009 at 7:31

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
Sorry for not posting earlier. My libSDL.a which I have used in the past 
carries the
date 7-13-2008. Here the speed varies with the depth, 8 bit is the fastes by 
far.

I now ported a new game to SDL. I have to use 16-bit depth with the current SDL 
lib
(for me this is 4-23-2009) which results in lines which are not clear. I hope 
the new
version will improve this.

Original comment by [email protected] on 12 Jul 2009 at 2:55

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
Use the SVN I think you'll find 16bit is the fastest. 8 and 24 bit basically 
create a
16bit texture then process it.  If you're using SDL from 7-13-2008 then it's not
using GX for rendering.

Original comment by [email protected] on 12 Jul 2009 at 6:19

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024

Original comment by [email protected] on 23 Jul 2009 at 6:27

  • Changed state: Fixed

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024

Original comment by [email protected] on 27 Jul 2009 at 7:10

  • Changed state: Started

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024
ok, this is reasonably fixed; however, using 24/32 bpp is highly discouraged 
for 
performance reasons. typically games will also support 16 bpp (recommended)

Original comment by [email protected] on 4 Aug 2009 at 7:20

  • Changed state: Fixed

from sdl-wii.

GoogleCodeExporter avatar GoogleCodeExporter commented on July 19, 2024

Original comment by [email protected] on 4 Aug 2009 at 8:52

  • Changed state: Completed

from sdl-wii.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.