Comments (16)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Original comment by [email protected]
on 23 Jul 2009 at 6:27
- Changed state: Fixed
from sdl-wii.
Original comment by [email protected]
on 27 Jul 2009 at 7:10
- Changed state: Started
from sdl-wii.
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.
Original comment by [email protected]
on 4 Aug 2009 at 8:52
- Changed state: Completed
from sdl-wii.
Related Issues (20)
- Undefined references to KEYBOARD functions HOT 1
- Keyboard has to be reconnected again to work :-( HOT 3
- Put SDL in portlibs directory? HOT 1
- Crash when unloading OGG music file HOT 2
- Wont compile HOT 2
- SMPEG Linking Errors When Using SDL_Mixer HOT 2
- Library does not work properly with libogc 1.8.7 HOT 1
- LIBPNG VERSION HOT 4
- SDL_Delay HOT 1
- SDL_image does not compile HOT 2
- Mouse emulation not working. HOT 3
- configure script fails due to devkitPPC unitptr_t conflict HOT 10
- Stereo for sound effects is reversed. HOT 1
- Mouse sensitivity HOT 2
- 640 X 512 screen resolution
- Font redering HOT 3
- Wireless USB Keyboard not working
- Gamecube controller support HOT 2
- SDL_CondWaitTimeout makes an incorrect timespec HOT 5
- SDL_KillThread is not working
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sdl-wii.