Menu
▾
▴
cadcdev-tiki — Discussion about the Tiki cross-platform toolkit
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(131) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(4) |
Feb
(16) |
Mar
|
Apr
(15) |
May
(18) |
Jun
(25) |
Jul
(13) |
Aug
|
Sep
(3) |
Oct
|
Nov
(7) |
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(11) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dan P. <ba...@al...> - 2006-05-12 15:48:09
|
On May 11, 2006, at 7:39 PM, Sam Steele wrote: > Hmm, odd. I don't run into a problem when rendering the screen > with GL_QUADS in KGL, only when using plx-compat. It draws the > entire background array on the opaque list, then draws almost half > of the foreground on the translucent list (on the last character it > tries to render, it only draws 1 of the two triangles). I'm not > seeing any messages on the dc-load console, so I have no idea > what's up. Any ideas? DR would be one explanation actually -- KGL appears to transform all the verts at once (with one mat_transform call) and send them to the TA using DR, while the plx_compat stuff would send them as triangle strips, probably not with the same efficiency. So it could actually be a memory bandwidth issue rather than a rendering time issue. You'd be sending the same verts but less efficiently. Aside from that though, I think we shouldn't be using plxcompat on the DC. We might ought to figure out a way to use the real plx stuff because it's quite a bit faster, especially with DR. Not 100% sure how that would work (especially as how you don't need a DR context under other OSes even if you use the plx_compat functions with DR ^_^;) but it'd be nice. Then if something needs to run nicely on a DC you can just write your stuff with plx calls and be good on all platforms (FoF was done this way, e.g.). |
|
From: Sam S. <sam...@gm...> - 2006-05-12 02:39:25
|
On May 11, 2006, at 10:15 PM, Dan Potter wrote: > The PVR seems capable of drawing quads, but no one's really figured > it out 100%. Everything else just uses triangle strips for > everything, even single triangles. :) So yeah, GL_QUADS won't help > you much -- that'll just get rendered as a two triangle strip. > Hmm, odd. I don't run into a problem when rendering the screen with GL_QUADS in KGL, only when using plx-compat. It draws the entire background array on the opaque list, then draws almost half of the foreground on the translucent list (on the last character it tries to render, it only draws 1 of the two triangles). I'm not seeing any messages on the dc-load console, so I have no idea what's up. Any ideas? Btw, I'm not going to check it into Tiki until I get Atani's ANSI code in, but if you'd like to see the code I have now it's checked into my public SVN repo with DreamZZT: http://svn.c99.org/svn/DreamZZT/trunk/src/Drawables/ConsoleText.cpp http://svn.c99.org/svn/DreamZZT/trunk/include/drawables/ConsoleText.h |
|
From: Dan P. <ba...@al...> - 2006-05-12 02:15:41
|
On May 11, 2006, at 5:13 PM, Sam Steele wrote: > What's the recommended way to draw GL_QUADS from inside a > Drawable? the plx_compat stuff the existing drawables are using > only does triangle strips. I currently have all my characters > being rendered as 2 triangles (like banner) plus 2 triangles for > the background block behind it, but that results in 8000 polys for > an 80x25 screen, which is just slightly too many for the PVR to > render (it gives up after drawing the background, and 49% of the > foreground polys). Using GL_QUADS instead would require only 4000 > polys, which the Dreamcast likes a lot better :) Should I just use > glBegin(GL_QUADS); etc. inside my drawable and use the GL vertex > calls? The PVR seems capable of drawing quads, but no one's really figured it out 100%. Everything else just uses triangle strips for everything, even single triangles. :) So yeah, GL_QUADS won't help you much -- that'll just get rendered as a two triangle strip. |
|
From: Sam S. <sam...@gm...> - 2006-05-12 00:14:09
|
What's the recommended way to draw GL_QUADS from inside a Drawable? the plx_compat stuff the existing drawables are using only does triangle strips. I currently have all my characters being rendered as 2 triangles (like banner) plus 2 triangles for the background block behind it, but that results in 8000 polys for an 80x25 screen, which is just slightly too many for the PVR to render (it gives up after drawing the background, and 49% of the foreground polys). Using GL_QUADS instead would require only 4000 polys, which the Dreamcast likes a lot better :) Should I just use glBegin(GL_QUADS); etc. inside my drawable and use the GL vertex calls? -Sam |
|
From: Dan P. <ba...@al...> - 2006-05-07 00:18:44
|
On May 6, 2006, at 2:20 PM, Sam Steele wrote: > Since the notification emails aren't working, I'll post one myself :-P > > I checked in some changes to hid that handle modifier keys (shift/ > ctrl/alt) on SDL and OS X, as well as adding key repeating > (KeyPress only, not KeyDown, just like OS X) to SDL. I also fixed > a typo in Time::sleep() for SDL that prevented it from working. > > I should have the keyboard changes in for Win32 soon too. I have no clue why the notifications aren't working again. This time the script to do them is installed and working fine. I can go in and run it manually and they show up... We need to get this crud moved off to SF. Maybe I can do that this weekend if I have a minute tomorrow. Time's been a bit scarce at home for computer stuff lately. If one of you guys wants to do it, too, let me know and I can provide you with an svnadmin dump of the repo and any required security access. I think that's what they need. |
|
From: Sam S. <sam...@gm...> - 2006-05-06 21:20:49
|
Since the notification emails aren't working, I'll post one myself :-P I checked in some changes to hid that handle modifier keys (shift/ ctrl/alt) on SDL and OS X, as well as adding key repeating (KeyPress only, not KeyDown, just like OS X) to SDL. I also fixed a typo in Time::sleep() for SDL that prevented it from working. I should have the keyboard changes in for Win32 soon too. -Sam |
|
From: Sam S. <sam...@gm...> - 2006-05-06 17:33:24
|
Not yet, but while I was porting it I remembered why I need to get =20
that in there ASAP:
ct->color(11,1);
ct->printf("Use ");
ct->color(15,1);
ct->printf("%c ",24);
ct->color(11,1);
ct->printf("and ");
ct->color(15,1);
ct->printf("%c ",25);
ct->color(11,1);
ct->printf("to scroll and press ");
ct->color(15,1);
That could all be on one statement with ANSI support :) I'll work on =20=
that this weekend too.
-Sam
On May 6, 2006, at 6:09 AM, Atani wrote:
> Nice, is this using any of the code from my cvs stuff?
>
> Mike
>
> On 5/5/2006, "Sam Steele" <sam...@gm...> wrote:
>
>> And after 8 hours of hacking, DreamZZT now compiles and runs under
>> Tiki :-D This weekend I'll finish cleaning up the drawable's code
>> and get it ready to check into SVN. Screenshot: http://
>> webdav.c99.org/sam/dreamzztiki.png
>>
>> -Sam
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, =20
>> security?
>> Get stuff done quickly with pre-integrated technology to make your =20=
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
>> Geronimo
>> http://sel.as-us.falkag.net/sel?=20
>> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
>> _______________________________________________
>> cadcdev-tiki mailing list
>> cad...@li...
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki
>>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642=
> _______________________________________________
> cadcdev-tiki mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki
|
|
From: Atani <at...@at...> - 2006-05-06 17:27:13
|
Nice, is this using any of the code from my cvs stuff? Mike On 5/5/2006, "Sam Steele" <sam...@gm...> wrote: >And after 8 hours of hacking, DreamZZT now compiles and runs under >Tiki :-D This weekend I'll finish cleaning up the drawable's code >and get it ready to check into SVN. Screenshot: http:// >webdav.c99.org/sam/dreamzztiki.png > >-Sam > > >------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easie= r >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D12= 1642 >_______________________________________________ >cadcdev-tiki mailing list >cad...@li... >https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Sam S. <sam...@gm...> - 2006-05-06 05:57:54
|
And after 8 hours of hacking, DreamZZT now compiles and runs under Tiki :-D This weekend I'll finish cleaning up the drawable's code and get it ready to check into SVN. Screenshot: http:// webdav.c99.org/sam/dreamzztiki.png -Sam |
|
From: Dan P. <ba...@al...> - 2006-04-28 04:06:25
|
It's really not a quirk but sort of "behaves as designed". A pointer
is a totally distinctive type from an object instance in C++. If you
dereference it, it becomes an object reference. So yeah, you can't
use operator<< on a pointer. :\ You might be able to do something
like this though:
inline operator<<(ConsoleText *, foo) {
}
i.e. not part of a class. I'm not sure if that'll work but it might
let you.
This example you gave is probably one of the reasons they added the
'references' in C++ instead of just keeping pointers. That way you
can basically pass pointers but you can treat them like objects. I
just wish you could legally have null references and reassign them.
On Apr 27, 2006, at 8:53 PM, Sam Steele wrote:
> I ran into another C++ quirk while working on TikiSnake. If you
> look at the code, you'll see that I have to have my Drawable be an
> actual object, not a pointer, otherwise C++ complains about my
> overloaded << operator. The following works fine:
>
> ConsoleText ct(blah);
>
> ct << "Hello world!";
>
> But the following doesn't:
>
> ConsoleText *ct = new ConsoleText(blah);
>
> ct << "Hello world!";
>
> /Users/sam/Projects/Console/src/snake.cpp:73: error: invalid
> operands of types 'Tiki::GL::ConsoleText*' and 'const char [13]' to
> binary 'operator<<'
>
> You can do:
>
> *ct << "Hello world";
>
> But the syntax looks a little quirky.
>
> Is there a way to tweak my declaration of the << operator to allow
> it to work through a pointer?
>
> -Sam
|
|
From: Sam S. <sam...@gm...> - 2006-04-28 03:53:47
|
I ran into another C++ quirk while working on TikiSnake. If you look at the code, you'll see that I have to have my Drawable be an actual object, not a pointer, otherwise C++ complains about my overloaded << operator. The following works fine: ConsoleText ct(blah); ct << "Hello world!"; But the following doesn't: ConsoleText *ct = new ConsoleText(blah); ct << "Hello world!"; /Users/sam/Projects/Console/src/snake.cpp:73: error: invalid operands of types 'Tiki::GL::ConsoleText*' and 'const char [13]' to binary 'operator<<' You can do: *ct << "Hello world"; But the syntax looks a little quirky. Is there a way to tweak my declaration of the << operator to allow it to work through a pointer? -Sam |
|
From: Sam S. <sam...@gm...> - 2006-04-28 01:24:28
|
http://sigbox.c99.org/~sam/TikiSnake-0.1.tar.gz makes me happy. XCode project only, no makefile for linux of win32 project yet. I still have a lot of work to do before it's tiki-ready, but the groundwork has been laid! -Sam |
|
From: Dan P. <ba...@al...> - 2006-04-28 00:49:22
|
On Apr 27, 2006, at 1:12 PM, Sam Steele wrote: > Ah, I've been looking to add ANSI support for a while, but I > haven't had the chance, so I'll definitely check that out. I'd > also like to include some macros around the ANSI codes, so you > could do something like: > > cout << "Hello, " << COLOR(RED,BLACK) << "world!"; Cool. Might not want to make those part of TikiAll.h though, or make them inline functions in a namespace instead of macros. > On a semi-related topic, how do we want to structure data files in > the examples? romdisk/ doesn't really make so much sense outside > of KOS, how about resources/ or data/? Either of those sound good to me. There's nothing holy about using "romdisk" as the data dir even in KOS. :) I just chose that for early examples and it stuck. |
|
From: Sam S. <sam...@gm...> - 2006-04-27 20:12:38
|
Ah, I've been looking to add ANSI support for a while, but I haven't =20 had the chance, so I'll definitely check that out. I'd also like to =20 include some macros around the ANSI codes, so you could do something =20 like: cout << "Hello, " << COLOR(RED,BLACK) << "world!"; On a semi-related topic, how do we want to structure data files in =20 the examples? romdisk/ doesn't really make so much sense outside of =20 KOS, how about resources/ or data/? -Sam On Apr 27, 2006, at 3:11 AM, Atani wrote: > I agree very cool stuff... > > you might check out my old as-telnet project to get a working ANSI =20 > code > interpreter which should be easily convertable to Tiki. It handles > rendering and all for the traditional dos character set (including > special characters). > > you can find it in the CVS repository on http://sf.net/projects/=20 > atsoft/ > > Mike > > On 4/26/2006, "Dan Potter" <ba...@al...> wrote: > >> On Apr 26, 2006, at 7:29 PM, Sam Steele wrote: >> >>> Alright, I've been bitten by the ASCII bug again.. I'm looking into >>> converting my OpenGL ASCII console library (used by FrotzDC, >>> DreamZZT, my ghetto ASCII tetris and snake games, etc.) to be >>> contained in a Tiki drawable. It provides a BASIC-esque way of >>> outputting to the screen (locate(), color(), etc.), as well as C >>> (printf) and C++ (cout / cin objects). >>> >>> Is there any interest in adding this Drawable to Tiki (say >>> Tiki::GL::Console or something) or should I keep it as a separate >>> project? >> >> Sure, why not? That might be a cool thing to have. >> >> >> >> ------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, =20 >> security? >> Get stuff done quickly with pre-integrated technology to make your =20= >> job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20 >> Geronimo >> http://sel.as-us.falkag.net/sel?=20 >> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642 >> _______________________________________________ >> cadcdev-tiki mailing list >> cad...@li... >> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki >> > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, =20 > security? > Get stuff done quickly with pre-integrated technology to make your =20 > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache =20 > Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642= > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki |
|
From: Atani <at...@at...> - 2006-04-27 14:28:12
|
I agree very cool stuff... you might check out my old as-telnet project to get a working ANSI code interpreter which should be easily convertable to Tiki. It handles rendering and all for the traditional dos character set (including special characters). you can find it in the CVS repository on http://sf.net/projects/atsoft/ Mike On 4/26/2006, "Dan Potter" <ba...@al...> wrote: >On Apr 26, 2006, at 7:29 PM, Sam Steele wrote: > >> Alright, I've been bitten by the ASCII bug again.. I'm looking into >> converting my OpenGL ASCII console library (used by FrotzDC, >> DreamZZT, my ghetto ASCII tetris and snake games, etc.) to be >> contained in a Tiki drawable. It provides a BASIC-esque way of >> outputting to the screen (locate(), color(), etc.), as well as C >> (printf) and C++ (cout / cin objects). >> >> Is there any interest in adding this Drawable to Tiki (say >> Tiki::GL::Console or something) or should I keep it as a separate >> project? > >Sure, why not? That might be a cool thing to have. > > > >------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easie= r >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D12= 1642 >_______________________________________________ >cadcdev-tiki mailing list >cad...@li... >https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Dan P. <ba...@al...> - 2006-04-27 05:20:13
|
On Apr 26, 2006, at 7:29 PM, Sam Steele wrote: > Alright, I've been bitten by the ASCII bug again.. I'm looking into > converting my OpenGL ASCII console library (used by FrotzDC, > DreamZZT, my ghetto ASCII tetris and snake games, etc.) to be > contained in a Tiki drawable. It provides a BASIC-esque way of > outputting to the screen (locate(), color(), etc.), as well as C > (printf) and C++ (cout / cin objects). > > Is there any interest in adding this Drawable to Tiki (say > Tiki::GL::Console or something) or should I keep it as a separate > project? Sure, why not? That might be a cool thing to have. |
|
From: Sam S. <SAM...@GM...> - 2006-04-27 02:29:33
|
Alright, I've been bitten by the ASCII bug again.. I'm looking into converting my OpenGL ASCII console library (used by FrotzDC, DreamZZT, my ghetto ASCII tetris and snake games, etc.) to be contained in a Tiki drawable. It provides a BASIC-esque way of outputting to the screen (locate(), color(), etc.), as well as C (printf) and C++ (cout / cin objects). Is there any interest in adding this Drawable to Tiki (say Tiki::GL::Console or something) or should I keep it as a separate project? -Sam |
|
From: Dan P. <ba...@al...> - 2006-04-10 03:44:23
|
There's also a fix in this one for a fencepost error in the argument handling code in Win32. |
|
From: Sam S. <sam...@gm...> - 2006-04-08 19:08:06
|
On Apr 8, 2006, at 11:26 AM, Dan Potter wrote: > We definitely want this. I hadn't realized it wasn't there before > but that makes sense. Using m_txrdata looks totally appropriate. > Checked in. -Sam |
|
From: Dan P. <ba...@al...> - 2006-04-08 15:26:16
|
On Apr 7, 2006, at 2:58 PM, Sam Steele wrote: > Attached is a patch to twiddle textures loaded from image files, > which gives a huge increase in GL performance on the Dreamcast. > I'm using m_txrdata to point to the PVR memory (it seems to point > to the GL-formatted data on the PC side, which isn't touched from > the outside anyway), any objections to using that variable, or > should I add another one for the PVR pointer? I'll check it in if > there's no objections. We definitely want this. I hadn't realized it wasn't there before but that makes sense. Using m_txrdata looks totally appropriate. |
|
From: Dan P. <ba...@al...> - 2006-04-08 15:25:51
|
Nope, nothing has happened at all. I can try to get to that tomorrow. On Apr 7, 2006, at 11:28 PM, Atani wrote: > Dan, > Any updates on the migration to the SF SVN support? > > Mike > > On 2/25/2006, "Sam Steele" <sam...@gm...> wrote: > >> >> On Feb 25, 2006, at 2:49 PM, Dan Potter wrote: >> >>> It's now active for all projects. It looks like it'd be sufficient >>> for what we use it for. I was thinking about importing dcload into >>> the current KOS/Tiki repo, and then dumping that for import into >>> SourceForge if we want to proceed down that path. What do you guys >>> think? >> >> Sounds good, it should eliminate the CVS confusion anyway. Do I need >> to sign up for a SF account? >> >> -Sam > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Atani <at...@at...> - 2006-04-08 13:44:38
|
Dan, Any updates on the migration to the SF SVN support? Mike On 2/25/2006, "Sam Steele" <sam...@gm...> wrote: > >On Feb 25, 2006, at 2:49 PM, Dan Potter wrote: > >> It's now active for all projects. It looks like it'd be sufficient >> for what we use it for. I was thinking about importing dcload into >> the current KOS/Tiki repo, and then dumping that for import into >> SourceForge if we want to proceed down that path. What do you guys >> think? > >Sounds good, it should eliminate the CVS confusion anyway. Do I need >to sign up for a SF account? > >-Sam |
|
From: Atani <at...@at...> - 2006-04-08 13:43:12
|
I see no problems in using this field for this purpose. This field from
what I can tell is just used to store the texture after it has been
converted to GL format (on all platforms).
Do you have numbers show to the performance increase in using twiddled
txrs vs normal ones?
Mike
On 4/7/2006, "Sam Steele" <sam...@gm...> wrote:
>Attached is a patch to twiddle textures loaded from image files,
>which gives a huge increase in GL performance on the Dreamcast. I'm
>using m_txrdata to point to the PVR memory (it seems to point to the
>GL-formatted data on the PC side, which isn't touched from the
>outside anyway), any objections to using that variable, or should I
>add another one for the PVR pointer? I'll check it in if there's no
>objections.
>
>Thanks,
>Sam
>
>
>IIndex: texture.cpp
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>--- texture.cpp (revision 310)
>+++ texture.cpp (working copy)
>@@ -49,7 +49,11 @@
> m_w =3D m_h =3D 0;
> m_fmt =3D None;
> if (!initial && m_txrdata && m_txrdata !=3D oldptr)
>+#if TIKI_PLAT !=3D TIKI_DC
> delete[] m_txrdata;
>+#else
>+ //glDeleteTexture frees the PVR memory for us, how
>nice of it!
>+#endif
> m_txrdata =3D NULL;
> if (!initial && m_gltxr)
> glDeleteTextures(1, &m_gltxr);
>@@ -178,10 +182,6 @@
> memcpy(m_ptr, img->data, img->byteCount);
> }
>- /* We'll write the converted data into this buffer */
>- if (!m_txrdata)
>- m_txrdata =3D new uint8[img->w * img->h * 4];
>-
> m_w =3D img->w;
> m_h =3D img->h;
> m_fmt =3D (Fmt)(img->fmt);
>@@ -204,6 +204,10 @@
> glBindTexture(GL_TEXTURE_2D, m_gltxr);
>#if TIKI_PLAT !=3D TIKI_DC
>+ /* We'll write the converted data into this buffer */
>+ if (!m_txrdata)
>+ m_txrdata =3D new uint8[img->w * img->h * 4];
>+
> convertToGl();
> glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
> glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
>@@ -211,10 +215,13 @@
> GLenum err =3D glGetError();
>#else
>+ m_txrdata =3D (uint8 *)pvr_mem_malloc(img->w * img->h * 2);
>+ pvr_txr_load_ex(m_ptr, m_txrdata, img->w, img->h,
>PVR_TXRLOAD_16BPP);
>+
> if(use_alpha) {
>- glTexImage2D(GL_TEXTURE_2D, 0, GL_ARGB4444, m_w, m_h,
>0, GL_ARGB4444, GL_UNSIGNED_BYTE, m_ptr);
>+ glKosTex2D(GL_ARGB4444_TWID, m_w, m_h, m_txrdata);
> } else {
>- glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB565, m_w, m_h,
>0, GL_RGB565, GL_UNSIGNED_BYTE, m_ptr);
>+ glKosTex2D(GL_RGB565_TWID, m_w, m_h, m_txrdata);
> }
> glTexEnvi(GL_TEXTURE_2D,GL_TEXTURE_ENV_MODE,GL_MODULATEALPHA);
>#endif
|
|
From: Sam S. <sam...@gm...> - 2006-04-07 21:59:00
|
Attached is a patch to twiddle textures loaded from image files,
which gives a huge increase in GL performance on the Dreamcast. I'm
using m_txrdata to point to the PVR memory (it seems to point to the
GL-formatted data on the PC side, which isn't touched from the
outside anyway), any objections to using that variable, or should I
add another one for the PVR pointer? I'll check it in if there's no
objections.
Thanks,
Sam
IIndex: texture.cpp
===================================================================
--- texture.cpp (revision 310)
+++ texture.cpp (working copy)
@@ -49,7 +49,11 @@
m_w = m_h = 0;
m_fmt = None;
if (!initial && m_txrdata && m_txrdata != oldptr)
+#if TIKI_PLAT != TIKI_DC
delete[] m_txrdata;
+#else
+ //glDeleteTexture frees the PVR memory for us, how
nice of it!
+#endif
m_txrdata = NULL;
if (!initial && m_gltxr)
glDeleteTextures(1, &m_gltxr);
@@ -178,10 +182,6 @@
memcpy(m_ptr, img->data, img->byteCount);
}
- /* We'll write the converted data into this buffer */
- if (!m_txrdata)
- m_txrdata = new uint8[img->w * img->h * 4];
-
m_w = img->w;
m_h = img->h;
m_fmt = (Fmt)(img->fmt);
@@ -204,6 +204,10 @@
glBindTexture(GL_TEXTURE_2D, m_gltxr);
#if TIKI_PLAT != TIKI_DC
+ /* We'll write the converted data into this buffer */
+ if (!m_txrdata)
+ m_txrdata = new uint8[img->w * img->h * 4];
+
convertToGl();
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
@@ -211,10 +215,13 @@
GLenum err = glGetError();
#else
+ m_txrdata = (uint8 *)pvr_mem_malloc(img->w * img->h * 2);
+ pvr_txr_load_ex(m_ptr, m_txrdata, img->w, img->h,
PVR_TXRLOAD_16BPP);
+
if(use_alpha) {
- glTexImage2D(GL_TEXTURE_2D, 0, GL_ARGB4444, m_w, m_h,
0, GL_ARGB4444, GL_UNSIGNED_BYTE, m_ptr);
+ glKosTex2D(GL_ARGB4444_TWID, m_w, m_h, m_txrdata);
} else {
- glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB565, m_w, m_h,
0, GL_RGB565, GL_UNSIGNED_BYTE, m_ptr);
+ glKosTex2D(GL_RGB565_TWID, m_w, m_h, m_txrdata);
}
glTexEnvi(GL_TEXTURE_2D,GL_TEXTURE_ENV_MODE,GL_MODULATEALPHA);
#endif
|
|
From: Atani <at...@at...> - 2006-02-27 21:31:35
|
On 2/25/2006, "Sam Steele" <sam...@gm...> wrote: > >Sounds good, it should eliminate the CVS confusion anyway. Do I need >to sign up for a SF account? If the SVN stuff moves to SF please add my SF ID (atani) to the CADCDEV project so I have write access if I am not already on there. Mike |
2 messages has been excluded from this view by a project administrator.
