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: Sam S. <sam...@gm...> - 2005-12-23 16:48:39
|
Hmm.. I browsed the site pretty quickly -- doesn't look like it has a RAD plugin for MFC, but it does have one for wxWidgets. Considering I have to redistribute MFC with my apps anyway, maybe I should look into using wxWidgets instead, though I haven't really been too impressed by wxWidgets-based apps on linux.. maybe it's better on Windows. I'll have to try it out this weekend I guess. I wonder how hard it would be to add a wxWidgets GUI to a Tiki app -- I'm only really familiar with Cocoa, and I know a little bit of MFC and GTK+. Btw, have you tried out the SVN plugin? -Sam On 12/23/05, atani <at...@at...> wrote: > > > Its a cheap alternative to MSVC... And it works with the VC .NET 2003 > free compiler too! > > I have been using it for about a week now on windows (fighting with > getting Tiki to compile cleanly in it, downloading dependencies, > etc). I have it compiled and mostly usable on linux as well, but I > think it is fubar'd on my linux build. > > Mike > > > On Dec 22, 2005, at 6:44 PM, Sam Steele wrote: > > > I've been hearing a lot about Code::Blocks lately. Is it any good? > > > > -Sam > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: atani <at...@at...> - 2005-12-23 16:01:05
|
Its a cheap alternative to MSVC... And it works with the VC .NET 2003 free compiler too! I have been using it for about a week now on windows (fighting with getting Tiki to compile cleanly in it, downloading dependencies, etc). I have it compiled and mostly usable on linux as well, but I think it is fubar'd on my linux build. Mike On Dec 22, 2005, at 6:44 PM, Sam Steele wrote: > I've been hearing a lot about Code::Blocks lately. Is it any good? > > -Sam |
|
From: Sam S. <sam...@gm...> - 2005-12-23 02:44:11
|
I've been hearing a lot about Code::Blocks lately. Is it any good? -Sam |
|
From: Dan P. <ba...@al...> - 2005-12-22 17:55:56
|
On Dec 22, 2005, at 4:46 AM, Sam Steele wrote: > Here's the exact warning: > > Tiki.framework/PrivateHeaders/hid.h: In constructor > 'Tiki::Hid::Event::Event()': > Tiki.framework/PrivateHeaders/hid.h:126: warning: > 'Tiki::Hid::Event::port' will be initialized after > Tiki.framework/PrivateHeaders/hid.h:120: warning: 'int > Tiki::Hid::Event::key' > Tiki.framework/PrivateHeaders/hid.h:113: warning: when > initialized here Interesting. I actually just heard about this from someone at work the other day for the first time: if you do the initialization lists in a constructor, it will execute them in the order they appear in the class, not the order specified on the constructor. Which seems incredibly stupid to me. But whatever, I'm not the C++ designer. :) Since I learned that I've switched to using pretty much exclusively in-function initialization unless it's not possible (e.g. references). The init lists just seem deceptive and confusing to me now. At least GCC does warn about it, though that particular warning seems kinda useless since port and key don't depend on each other... |
|
From: Sam S. <sam...@gm...> - 2005-12-22 12:47:07
|
Here's the exact warning: Tiki.framework/PrivateHeaders/hid.h: In constructor 'Tiki::Hid::Event::Event()': Tiki.framework/PrivateHeaders/hid.h:126: warning: 'Tiki::Hid::Event::port' will be initialized after Tiki.framework/PrivateHeaders/hid.h:120: warning: 'int Tiki::Hid::Event::key' Tiki.framework/PrivateHeaders/hid.h:113: warning: when initialized here It only seems to occur when building TikiBlap, not TikiSquares. I think it might have to do with TikiBlap not using pre-compiled headers, I'll play around it with it again after work, but changing the header seemed to satisfy it for now. -Sam On Dec 22, 2005, at 7:24 AM, Sam Steele wrote: > Warning: "port" is initialized before "key" when declared here. I > got tired of seeing it over and over again :-P I guess it had to > do with the order of the variables on the default constructor, but > it was easier to cut/paste vertically rather than horizontally so I > moved it in the class. > > -Sam > > On Dec 22, 2005, at 12:01 AM, Dan Potter wrote: > >> This one gave me a double take. :) What was g++ doing there? >> >> On Dec 21, 2005, at 6:45 PM, cadcdev-svn- >> co...@li... wrote: >> >>> Tiki: Move port before key in declaration so g++ stops complaining >> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD >> SPLUNK! >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >> _______________________________________________ >> cadcdev-tiki mailing list >> cad...@li... >> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Sam S. <sam...@gm...> - 2005-12-22 12:24:57
|
Warning: "port" is initialized before "key" when declared here. I got tired of seeing it over and over again :-P I guess it had to do with the order of the variables on the default constructor, but it was easier to cut/paste vertically rather than horizontally so I moved it in the class. -Sam On Dec 22, 2005, at 12:01 AM, Dan Potter wrote: > This one gave me a double take. :) What was g++ doing there? > > On Dec 21, 2005, at 6:45 PM, cadcdev-svn- > co...@li... wrote: > >> Tiki: Move port before key in declaration so g++ stops complaining > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki |
|
From: Dan P. <ba...@al...> - 2005-12-22 05:01:46
|
This one gave me a double take. :) What was g++ doing there? On Dec 21, 2005, at 6:45 PM, cadcdev-svn- co...@li... wrote: > Tiki: Move port before key in declaration so g++ stops complaining |
|
From: Dan P. <ba...@al...> - 2005-12-19 01:02:06
|
On Dec 18, 2005, at 1:50 PM, Sam Steele wrote: > The nextFrame function in the Drawable class takes a uint64 tm. > Should this be the relative time since the last frame, or the > absolute time since the menu started? > > Tiki's built-in visualPerFrame is always passing this as zero, but > I've modified my copy to pass the time since the last frame > instead. Any objections to committing this? I think I meant it to be an absolute value from some arbitrary offset (perhaps based on the Timeline or whatever). In practice that's not nearly as useful as a delta since the last update. So maybe that'd be better. Somehow it seems like passing in a Timeline might be even better idea but I'm not 100% sure how that'd work... |
|
From: Sam S. <sam...@gm...> - 2005-12-18 21:51:08
|
The nextFrame function in the Drawable class takes a uint64 tm. Should this be the relative time since the last frame, or the absolute time since the menu started? Tiki's built-in visualPerFrame is always passing this as zero, but I've modified my copy to pass the time since the last frame instead. Any objections to committing this? -Sam |
|
From: Sam S. <sam...@gm...> - 2005-12-15 20:00:30
|
Sounds fun, I have some changes to check into KOS (the one on the mailing list, plus another change I made to fs_iso9660 myself earlier). I'll try t= o commit them tonight, but if they don't go through then I'll know why :) -Sam |
|
From: Dan P. <ba...@al...> - 2005-12-15 18:46:39
|
More fun with this topic. I'm having my DSL service rearranged some time today (hopefully) so the SVN server could be out for a while (where "a while" means up to a day or two). So if you have any sync'ing or checking-in todo that is important, might want to do it now! |
|
From: Dan P. <ba...@al...> - 2005-12-04 16:59:43
|
On Dec 4, 2005, at 8:21 AM, Sam Steele wrote:
> Right now I'm keeping my own std::list<Entity *> of Entity pointers
> so I don't lose them when they turn into Drawables in the list, but
> I'm guessing RTTI would let me enumerate genmenu's m_scene to find
> Entity-derived objects, and cast them from a Drawable pointer to an
> Entity pointer to use the Entity-specific functions?
Yes. You can take any pointer and try to upcast it to any other
pointer, and if it's possible it'll give you the new pointer;
otherwise it'll return NULL. If you do the same with an object or a
reference, it'll throw an exception if it fails.
One thing to be clear about, dynamic_cast is most useful for
upcasting or cross-casting (which I think is what you want to do
here). For example:
A -> B -> C
X -> Y /
What my bad ASCII art there is saying is that B derives from A, Y
derives from X, and C derives from B and Y. In this case, you ought
to be able to cast a C to any of those things without any RTTI
voodoo. You can also take an A* which is actually a C, and up-cast it
to a C; RTTI lets you do this safely, if you don't know the A is a C
already. Similarly if you have an X* which is actually a C, you can
use RTTI to upcast to C, and I think you might be able to cross-cast
to A or B (maybe with an intermediate C* cast), but again that's not
too safe without using RTTI to check.
> create_object("Paddle") returns an Entity* which is pointing to a
> Paddle*. If I then call ent->loadFromFile(), then
> Entity::loadFromFile() gets called, but not Paddle::loadFromFile
> (). I think that's what the virtual keyword is for? Anyway, for
> now I just have a second giant if/else called load_object() that
> calls loadFromFile before the object gets cast to an Entity*.
If I'm understanding correctly, it sounds like one way or another the
compiler isn't seeing the virtual applying to what you're applying it
to. That's the behavior you'd get if you had some method in both
classes without 'virtual'. Another way this can happen is if you try
to use it from the constructor. Calling virtuals from the constructor
is a bad idea (ditto with the destructor). If you think about it for
a minute you can see why. :) They made the language patch up the
vtable at each step of construction/destruction to make this not as
bad as it could be, but IMO they should've just made it illegal...
Also the base class must be called explicitly from the derived
method. This lets you wholly override functionality from a base class
and also have better control over when the base class method gets
called (before or after, etc). Unfortunately there's no smart way in C
++ to address the base class. So somewhere in your
Paddle::loadFromFile() you need to have something like
"Entity::loadFromFile()".
> Now, m_light gets assigned a pointer in a linked list of where
> lights are located (to make finding them as fast as possible for
> vertex lighting). Anyway, it gets a value inside of Light();, but
> as soon as it returns from that call, it goes back to being NULL
> again before loadFromFile gets called. Is there another way I'm
> supposed to call the default constructor from another constructor?
AFAIK you can't call another constructor on the same object directly
(someone correct me here if I'm wrong, because I'm a little fuzzy on
this point). The standard idiom is this:
class Foo {
public:
Foo();
Foo(int a);
Foo(int a, int b);
private:
void init(int a, int b);
};
Foo::Foo() {
init(defa, defb);
}
Foo::Foo(int a) {
init(a, defb);
}
Foo::Foo(int a, int b) {
init(a, b);
}
void Foo::init(int a, int b) {
// Real constructor guts
}
|
|
From: Sam S. <sam...@gm...> - 2005-12-04 16:38:58
|
One more C++ thing I noticed:
I have a class called Light that's derived from Entity, in the
default constructor I have:
Light::Light() {
m_light=create_light();
}
Now, in the constructor that takes a Tiki::File, I didn't want to
duplicate the above line, so I tried:
Light::Light(Tiki::File f) {
Light();
loadFromFile(f);
}
Now, m_light gets assigned a pointer in a linked list of where lights
are located (to make finding them as fast as possible for vertex
lighting). Anyway, it gets a value inside of Light();, but as soon
as it returns from that call, it goes back to being NULL again before
loadFromFile gets called. Is there another way I'm supposed to call
the default constructor from another constructor?
-Sam
|
|
From: Sam S. <sam...@gm...> - 2005-12-04 16:21:47
|
On Nov 27, 2005, at 3:52 PM, Dan Potter wrote:
> - And about Drawables in lists...:
>
R.I.P 2001 - 2005 entity.h, callback.h / callback.cc, collide.h /
collide.cc, and a host of other files related to AOE, the core of
DreamZZT and DCBlap (and the misc 3D demos that use the DCBlap
engine). I took the plunge and practically rewrote DCBlap using Tiki
Drawables!
To be honest, it wasn't as difficult as I thought, though it requires
changing your mindset around going from C-style programming to C++
OOP (load_world() doesn't load the objects anymore, it creates an
object and the object loads itself from the file, etc.). Now the
entire game world is packed neatly into a genmenu scene, using Tiki
selectors for messaging.
> If we turn on RTTI (I think it might work on the DC now, and might
> be a good thing to have overall) then you can also use dynamic_cast
> to check to make sure that a particular pointer is the class you
> think it is, if you need to do that.
>
Right now I'm keeping my own std::list<Entity *> of Entity pointers
so I don't lose them when they turn into Drawables in the list, but
I'm guessing RTTI would let me enumerate genmenu's m_scene to find
Entity-derived objects, and cast them from a Drawable pointer to an
Entity pointer to use the Entity-specific functions?
> The type switch on creation is pretty ugly but there's no really
> good way around that in C++
>
Yeah, I opted for the giant if/else function for now. I figure I can
just generate it with a shell script, like the old object-template
creation function was. I actually have two of them, because of what
I assume is another C++ "feature":
create_object("Paddle") returns an Entity* which is pointing to a
Paddle*. If I then call ent->loadFromFile(), then
Entity::loadFromFile() gets called, but not Paddle::loadFromFile().
I think that's what the virtual keyword is for? Anyway, for now I
just have a second giant if/else called load_object() that calls
loadFromFile before the object gets cast to an Entity*.
As for the menus, I went and recreated them as a bunch of drawables
-- the help text is now a few labels and banners for the controller
icons. It looks much better, and it's easier to swap the icons out
for PC keyboard images on the PC (though, drawing a D-Pad was a lot
easier than drawing the arrow keys on a PC.. grr).
I've still got a long way to go with writing the new object classes,
so nothing playable this week -- right now it's been reduced to a
paddle that kind-of responds to the keyboard, and a ball that makes
drawables turn red with setTint when it collides with them.
-Sam
|
|
From: Dan P. <ba...@al...> - 2005-11-29 23:08:44
|
On Nov 29, atani wrote: > Cool :) In m y day job I mostly work in Java now so my C++ gets a > bit of influence from that nowadays.. Yeah, we're doing a lot of C# these days. I did Java earlier, the two are kind of surprisingly similar (or not very suprising when you consider why MS built C# :) > Perhaps having an enum on Texture which we can add these as "flags"? > That way we can have a unified "base" which returns something like > "not implemented" for things like VQ/twiddle and then on the DC port > we can override this with a proper implementation. Right. Or maybe down in Image since it has flags already and source images would probably get loaded that way most of the time. Texture could make use of the flags in Image also. > Another thing to consider could be usage of exceptions within Tiki? We've also been doing more of this at work. It's funny, these guys started working with C++ when it was first coming out, basically just a preprocessor around C. The attitudes from that time more or less got stuck, so we have a lot of weird and gross stuff in the code base from the dawn of time. Then we hired a bunch of new people who've studied modern C++ standards, design patterns, etc. Their influence is starting to cause us to use things like exceptions finally. Well, that and MS building a *working* C++ compiler :) I'm somewhere in between. I like the plain bare-bones C++, especially in an embedded situation, but I'm starting to like exceptions and RTTI a lot more after using them in Java and C#. Exceptions would sure beat some of the dumb 'assert' statements I have scattered around in some inappropriate places ;) |
|
From: atani <at...@at...> - 2005-11-29 22:51:00
|
Dan,
Once you have had a chance to look at the Texture rewrite I
would like to implement non power-of-two texture support. Right now
to have a "fullscreen" texture I have to create a texture that is
like 1024x512 and then set the size on the Banner to 640x480. In a
previous Tiki modification I had added partial support for this by
having a "Canvas" and "Image" sizes stored in the Texture object.
The basics of it was in Banner checking the X/Y size vs the X/Y
Canvas size, if they differ it would calculate the UV values based on
XY value instead of Canvas XY values.
Ideally this would be better suited to be owned in the Texture class,
perhaps we can move the default UV value stuff into Texture instead
of Banner? Banner should still be able to "override" UV values from
the Texture.
Mike
|
|
From: atani <at...@at...> - 2005-11-29 18:26:07
|
On Nov 29, 2005, at 9:34 AM, Dan Potter wrote: > That's not a bad plan. We've been discussing a lot of this design > pattern stuff at work, re C++ commonly accepted practice. So I may > take a shot at this soon. Maybe I'll actually have some time on it > tonight if my wife doesn't lock her keys in the car again ;) > Cool :) In m y day job I mostly work in Java now so my C++ gets a bit of influence from that nowadays.. > > Yeah, true. It might be nice to have some platform-specific support > for pre-twiddled textures in there too, to avoid doing that > processing at runtime if it's possible. Similar things could be > done for DXT(?) encoded textures on GL platforms. Perhaps having an enum on Texture which we can add these as "flags"? That way we can have a unified "base" which returns something like "not implemented" for things like VQ/twiddle and then on the DC port we can override this with a proper implementation. Another thing to consider could be usage of exceptions within Tiki? Mike |
|
From: Dan P. <ba...@al...> - 2005-11-29 17:34:39
|
On Nov 28, 2005, at 1:00 PM, atani wrote: > This is the current allocations that I can spot in the code: > Texture::loadFromFile(...): > m_ptr contains the "raw" image data > m_txrdata contains the ARGB8888 data used in the glTexImage2D call > > m_ptr can equal m_txrdata if the image file is in ARGB8888 format. > If not, m_ptr is allocated and the "raw" image data is memcpy into > it. Ideally this can be avoided by moving "img" from being a > method variable to a class member variable and then m_ptr can be > destroyed (maybe). Yeah, that sounds right. > Here is what I suggest :) > > 1) Take current Texture class and rename it to DynamicTexture and > remove the support for loading image files. This in effect would > become the "palette" based Texture class. > 2) Create a new ImageTexture class that supports only loading from > a file. Remove support for getPtr(), canvasLock(), canvasUnlock(). > 3) Move "common" bits to a new pure virtual Texture class so we can > still bind a Texture to Banner, etc. Using a pure virtual class > would be good in this case since it can be treated as an > "interface" of sorts rather than a normal class. However, a normal > class which we extend to add "extra" functionality would also work, > similar to Object. That's not a bad plan. We've been discussing a lot of this design pattern stuff at work, re C++ commonly accepted practice. So I may take a shot at this soon. Maybe I'll actually have some time on it tonight if my wife doesn't lock her keys in the car again ;) > True, the DC does have paletted textures, but IIRC the texture data > must be twiddled so we will need to keep that in mind as well. Yeah, true. It might be nice to have some platform-specific support for pre-twiddled textures in there too, to avoid doing that processing at runtime if it's possible. Similar things could be done for DXT(?) encoded textures on GL platforms. |
|
From: atani <at...@at...> - 2005-11-28 21:00:56
|
On Nov 28, 2005, at 10:06 AM, Dan Potter wrote: > > If that's true, I think the ARGB8888 data is totally unnecessary. A > good first step might be to free that up as soon as it's loaded > with GL. > This is the current allocations that I can spot in the code: Texture::loadFromFile(...): m_ptr contains the "raw" image data m_txrdata contains the ARGB8888 data used in the glTexImage2D call m_ptr can equal m_txrdata if the image file is in ARGB8888 format. If not, m_ptr is allocated and the "raw" image data is memcpy into it. Ideally this can be avoided by moving "img" from being a method variable to a class member variable and then m_ptr can be destroyed (maybe). Here is what I suggest :) 1) Take current Texture class and rename it to DynamicTexture and remove the support for loading image files. This in effect would become the "palette" based Texture class. 2) Create a new ImageTexture class that supports only loading from a file. Remove support for getPtr(), canvasLock(), canvasUnlock(). 3) Move "common" bits to a new pure virtual Texture class so we can still bind a Texture to Banner, etc. Using a pure virtual class would be good in this case since it can be treated as an "interface" of sorts rather than a normal class. However, a normal class which we extend to add "extra" functionality would also work, similar to Object. > > Keep in mind too that the DC has hardware paletted texture support. > So there might be something clever to be done there too. True, the DC does have paletted textures, but IIRC the texture data must be twiddled so we will need to keep that in mind as well. Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-28 18:17:15
|
On 11/28/05, Dan Potter <ba...@al...> wrote: > > If that's true, I think the ARGB8888 data is totally unnecessary. A > good first step might be to free that up as soon as it's loaded with GL. The Dreamcast bypasses this step, since ARGB8888 isn't supported by the PVR. I'm converting the original image into ARGB4444 or RGB565 depending o= n whether transparency is requested, and not using the second buffer at all (= I don't think it's even allocated). -Sam |
|
From: Dan P. <ba...@al...> - 2005-11-28 18:07:09
|
On Nov 28, 2005, at 7:58 AM, atani wrote: > I am not sure the copy is needed. Currently we have two blocks of > memory allocated for a texture, one in the original form (as loaded > from image file) and one in ARGB8888 form. Both of these are in > RAM not VRAM. Currently in lock/unlock we use the "original" > texture data and reconvert it to ARGB8888 on unlock. If that's true, I think the ARGB8888 data is totally unnecessary. A good first step might be to free that up as soon as it's loaded with GL. The reason I have it set up the way it's currently set up is because of exactly what Mike's talking about. I had some stuff that would stuff a new generated texture in each frame. What might be nicer is to specify somewhere that the texture will be used for that sort of purpose, and to keep the original form around. We can then move to GL- only textures for about 99% of the texture data and (especially on the DC) shortcut all those transforms and wasted memory. On those textures, lock()/unlock() would just fail. > For Palette based textures though, the original form is required to > ensure proper color mapping. It would be very slow to process the > ARGB8888 data back to palette data and then diff it to "current > palette" to get the new values. Keep in mind too that the DC has hardware paletted texture support. So there might be something clever to be done there too. |
|
From: atani <at...@at...> - 2005-11-28 15:58:54
|
On Nov 28, 2005, at 7:35 AM, Sam Steele wrote: > > We can probably copy the data out of VRAM and back into the texture > object when you lock the canvas, and copy it back in / release the > RAM when you unlock it. I am not sure the copy is needed. Currently we have two blocks of memory allocated for a texture, one in the original form (as loaded from image file) and one in ARGB8888 form. Both of these are in RAM not VRAM. Currently in lock/unlock we use the "original" texture data and reconvert it to ARGB8888 on unlock. For Palette based textures though, the original form is required to ensure proper color mapping. It would be very slow to process the ARGB8888 data back to palette data and then diff it to "current palette" to get the new values. Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-28 15:35:44
|
On 11/28/05, atani <at...@at...> wrote: > I am thinking of taking advantage of the fact that we store the > "original" texture data as well as the VRAM version. The way I am thinki= ng > of using this is for the palette based textures. Something along the lin= es > of old DOS mode 13 graphics (256 color, etc). I have most of these chang= es > in an older version of Tiki already but need to promote them to the lates= t. > We can probably copy the data out of VRAM and back into the texture object when you lock the canvas, and copy it back in / release the RAM when you unlock it. -Sam |
|
From: atani <at...@at...> - 2005-11-28 15:29:08
|
On Nov 27, 2005, at 12:52 PM, Dan Potter wrote: > > Also speaking of large textures... the texture handling in Tiki is > really crappy right now. :D I wrote it up as a quick hack to get > things moving, but it wastes a ton of VRAM and regular RAM. I think > it keeps a copy of the original texture in regular RAM, and then it > converts it to ARGB8888 and stuffs it into VRAM like that. I am thinking of taking advantage of the fact that we store the "original" texture data as well as the VRAM version. The way I am thinking of using this is for the palette based textures. Something along the lines of old DOS mode 13 graphics (256 color, etc). I have most of these changes in an older version of Tiki already but need to promote them to the latest. > That's probably especially bad on the DC unless you guys put in > some hacks to deal with it. We might want to hit that up if any > texture RAM optimizations are needed (which they assuredly will be > on a PC with less than 32MB of VRAM, especially Macs). If it is wasting space on the PC it will waste space on the DC likely as well. Mike |
|
From: Dan P. <ba...@al...> - 2005-11-28 05:56:58
|
On Nov 27, 2005, at 2:08 PM, Sam Steele wrote: > Now they work, and they look great. It looks like Jim's patch from > http://sourceforge.net/mailarchive/message.php?msg_id=10196955 > never made it into KOS. Was there a reason, or did it just get > lost in the shuffle? I applied it to Tiki, and the difference in > font quality is like night and day. I'll apply it to KOS and > commit it too if there's no objections. As I've probably mentioned many times before, there's a reason I was trying to get some extra maintainers on KOS. ^_^;; It's been sitting in my "flagged" folder in Mail for a loooong time now. Just never did it yet. Thanks for doing that. Also something that never got implemented, though this is a little bigger, is the CDDA reading that Thierry Vermeylen sent in. That's a little less pressing though... |
2 messages has been excluded from this view by a project administrator.
