You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(3) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
(38) |
May
(33) |
Jun
|
Jul
|
Aug
(31) |
Sep
|
Oct
(13) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
(12) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Martin W. <meh...@we...> - 2004-08-14 15:08:25
|
Hey, Arne Rempke wrote: > Hi, > >> I've added the following features to the menu: >> >> - is able to receive all types of characters like []/_#'+* ... and the >> german >> umlauts äöüß > > Works for most common characters but not for all (at least here). Please post which do not work. > >> - Implemented scrolling in menus. To test it set your resolution to >> 640x480 and >> go to the "Open game" menu where I left some test items. Enjoy it :D > > Seems to work quice nicely. Good. > >> Furthermore the behavior of CVideo::loadSurface() has changed: it uses >> CFileAccess now and therefore you MUST NOT call it with paths that are >> prepended >> with CDATADIR. Please adapt your sources. > > IIRC I only load Surfaces (map tiles) by using CFileAccess. There, I > don't give the full path but only the part behind CDATADIR, so I don't > think it's necessary to change it. > > But I can't start the game since I get a Segmentation fault when > CUnitManager tries to retrieve the image height of an (unloaded) unit > image. Would be great if Kris could fix it. I didn't know which sources were affected exactly, so I posted it in a global manner. Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-14 14:59:41
|
Hey, I've just written my own config lib WConfig for another project of mine and I think that it could be very usefully for craft. It is almost as fast as Kris' config lib and provides some more features than the config libs in /lib/ and /src/: - Gives detailled error messages to stderr when a parsing error occurs with exact position in file so that the user can correct errors easily. - Recognizes some more formats, I think. For example: str = "test test" and also any and any number of whitespaces between lines, keys, equal signs and values. (lib/cfglib.?pp has troubles with this, even it does not recognize any whitespace within a value) - These whitespaces are "corrected" to default (one space) when saving the config. In some ways this config lib might be more strict than the "old" ones: for example is str = foo bar wrong since the string was not embedded into double quotes although it contains whitespaces. What's your opinion? Shall we use it for craft? Code as attachment. Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Arne R. <arn...@gm...> - 2004-08-14 12:43:13
|
Hi, I zipped all tiles into zipfiles. So there are no .bmp or .tiles files in share/tiles. When I run make, I get make[2]: *** Keine Regel vorhanden, um das Target »tiles/*.bmp«, benötigt von »all-am«, zu erstellen. Schluss. (which means, that there is no rule for the target "tiles/*.bmp", which is needed by "all-am", and so it aborts). Did I forget to run an automake/-conf/...? Or is it just not possible to have no such files in share/tiles and such an entry in share/Makefile.am? If I unzip an archive, so that I have a bmp and a tile, make does everything without repining. cya arne |
From: Arne R. <arn...@gm...> - 2004-08-14 12:30:49
|
Hi, > due to my unbelievable brilliance ;) I was able to remove the previous event > types what means that we save one integer for each event stored. This was > achieved by replacing the old event types with C++ RTTI > (Run-Time-Type-Identification). Congratulations ;) cya arne |
From: Arne R. <arn...@gm...> - 2004-08-14 12:25:30
|
Hi, > I've added the following features to the menu: > > - is able to receive all types of characters like []/_#'+* ... and the german > umlauts äöüß Works for most common characters but not for all (at least here). > - Implemented scrolling in menus. To test it set your resolution to 640x480 and > go to the "Open game" menu where I left some test items. Enjoy it :D Seems to work quice nicely. > Furthermore the behavior of CVideo::loadSurface() has changed: it uses > CFileAccess now and therefore you MUST NOT call it with paths that are prepended > with CDATADIR. Please adapt your sources. IIRC I only load Surfaces (map tiles) by using CFileAccess. There, I don't give the full path but only the part behind CDATADIR, so I don't think it's necessary to change it. But I can't start the game since I get a Segmentation fault when CUnitManager tries to retrieve the image height of an (unloaded) unit image. Would be great if Kris could fix it. cya arne |
From: Martin W. <meh...@we...> - 2004-08-09 22:16:24
|
Hey, due to my unbelievable brilliance ;) I was able to remove the previous event types what means that we save one integer for each event stored. This was achieved by replacing the old event types with C++ RTTI (Run-Time-Type-Identification). This is, of course, only an internal change but it's worth to be noticed, I think ;) Good night, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-09 11:43:19
|
Hey, sry, forgot the mentioned attachment. Here it comes. Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-08-09 11:41:02
|
Hey, I've added the following features to the menu: - is able to receive all types of characters like []/_#'+* ... and the german umlauts äöüß - Implemented scrolling in menus. To test it set your resolution to 640x480 and go to the "Open game" menu where I left some test items. Enjoy it :D ATTENTION: To get the new menu started you will have to extract the attached archive within the share/ directory, update the sources via CVS and run a make install since the arrows declaring that scrolling is available were added. Furthermore the behavior of CVideo::loadSurface() has changed: it uses CFileAccess now and therefore you MUST NOT call it with paths that are prepended with CDATADIR. Please adapt your sources. Regards, martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) -- Mails von dieser Adresse sind nur gültig, wenn sie mit dem o. g. Schlüssel signiert wurden. Unsignierte Mails von dieser Adresse sind gefälscht und stehen in keinerlei Verbindung zu mir. Mails from this address are only valid if they are signed with the abovementioned key. Unsinged mails from this address are faked and have no relation to me. |
From: Martin W. <meh...@we...> - 2004-05-28 07:20:23
|
Hey, @arne: would you please be so kind and adapt your kernel sources the following way: - Call CMenu::preLoop() before the menu is called - Call CMenu::postLoop() after the menu is called - If craft shall quit MenuLoop() will return 0 - If a game shall be started an according CEventApplication is pushed Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Martin W. <meh...@we...> - 2004-05-28 07:20:14
|
Hello, Arne Rempke wrote: > [...] > I think casting all the time is also ugly. And it would be very slow > to make all eventpollers sort the uninteresting events out. If the > kernel listens to the events, a lot of the application events are > interesting, but all the other events like unitmovement are really > uninteresting. And I don't think the kernel is the only one. (The map > for example listens for scrolling events, but nothing else.) So it is > not very effective to make all game modules fetch all events and > afterwards filter them if they are interesting or not. > My suggestion is to merge some eventtypes. For example all these > applicational events. So we would have only three eventtypes at the > moment. > [...] I've thought for a long time about the possibilities how to solve this issue. At least I came to this result: I implemented your first suggestion and merged all applicational events into one event. What the event shall initiate is set by booleans. But I also implemented that the events are stored in one big vector. This involved that I had to re-introduce types but only internally. The interface for you (polling and pushing) remains! The necessary casts are now done by CEventSystem itself. So there is still no need for you to cast any event. I think this is the best I could make out of it. Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Arne R. <arn...@gm...> - 2004-05-27 20:51:25
|
Hi, > providing polling, pushing functions and implementing deques, cleaning > up and clearing for each new event is too much work and very ugly. So I > suggest to separate the events only into those that need to be cleaned > up and those that do not. Types will be re-introduced and also casting > will be necessary again. But I see no advantage of these many functions > and deques, ... . Currently we have 6 types of events what is hard at > the limit. But imaginge how many functions we get if we implement 10 or > more. I think this is not practicable. > > What's your opinion? I think casting all the time is also ugly. And it would be very slow to make all eventpollers sort the uninteresting events out. If the kernel listens to the events, a lot of the application events are interesting, but all the other events like unitmovement are really uninteresting. And I don't think the kernel is the only one. (The map for example listens for scrolling events, but nothing else.) So it is not very effective to make all game modules fetch all events and afterwards filter them if they are interesting or not. My suggestion is to merge some eventtypes. For example all these applicational events. So we would have only three eventtypes at the moment. Another possibility is: You save all the events in one large queue, and the pollers gibe you information about what they are searching for. That could be for example a bitset, where each bit represents one eventtype. If it is not set, events of this type can be skipped. The performance would be a bit better than your proposal, but not as good as my first suggestion. cya arne |
From: Martin W. <meh...@we...> - 2004-05-27 15:09:26
|
Hey, providing polling, pushing functions and implementing deques, cleaning up and clearing for each new event is too much work and very ugly. So I suggest to separate the events only into those that need to be cleaned up and those that do not. Types will be re-introduced and also casting will be necessary again. But I see no advantage of these many functions and deques, ... . Currently we have 6 types of events what is hard at the limit. But imaginge how many functions we get if we implement 10 or more. I think this is not practicable. What's your opinion? Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: <ben...@id...> - 2004-05-25 08:41:54
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Martin W. <meh...@we...> - 2004-05-23 18:16:07
|
Hey, Arne Rempke wrote: > [...] > >> Since you not answered: will you implement also this abality to load all >> tiles from DATADIR/tiles.zip or not? > > No, and I don't think it is necessary. The user should have the > ability of adding his own tilsets. So it makes no sense to put all the > global (not the map-specific) tilesets in only one zip file, because > it is much easier to just download a zip and put it into a directory > but not merge two zip files into one. And on the other hand, if we > offer this directory CDATADIR/tiles/ for all global tilesets, why > should "standard" or "base" tiles have their extra zipfile? Perhaps > the user does not like that at all and there are many other "standard" > tiles, why should it not be possible, to just delete our tilespack and > install another one? I don't think we should give our tiles a better > position than other add on tiles, since we want the game to be very > configurable. So, what's the problem with naming your pack of tiles > just "craft-base.zip" or something and putting it into the tiles > directory? > Very convincing arguments. You're right. Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Arne R. <arn...@gm...> - 2004-05-23 17:15:00
|
Hi, > Since you not answered: will you implement also this abality to load all > tiles from DATADIR/tiles.zip or not? No, and I don't think it is necessary. The user should have the ability of adding his own tilsets. So it makes no sense to put all the global (not the map-specific) tilesets in only one zip file, because it is much easier to just download a zip and put it into a directory but not merge two zip files into one. And on the other hand, if we offer this directory CDATADIR/tiles/ for all global tilesets, why should "standard" or "base" tiles have their extra zipfile? Perhaps the user does not like that at all and there are many other "standard" tiles, why should it not be possible, to just delete our tilespack and install another one? I don't think we should give our tiles a better position than other add on tiles, since we want the game to be very configurable. So, what's the problem with naming your pack of tiles just "craft-base.zip" or something and putting it into the tiles directory? cya arne |
From: Martin W. <meh...@we...> - 2004-05-23 13:59:09
|
Hey, Martin Wegner wrote: > <>[...] > But putting all tiles in [...]/share/craft/tiles.zip does not work! It's > not very suggestive to name it [...]/share/craft/tiles/tiles.zip . The > other options you mentioned were not tested by me. > Since you not answered: will you implement also this abality to load all tiles from DATADIR/tiles.zip or not? Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Martin W. <meh...@we...> - 2004-05-23 13:59:02
|
Hey, I've just committed a new src/Makefile.am which defines DATADIR as well as CDATADIR and CONFDIR as well as CCONFDIR. In the next future, we should adapt our sources to use CDATADIR and CCONFDIR to make this macros unique (especially important for windows builds using Dev-C++). Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Martin W. <meh...@we...> - 2004-05-23 13:58:55
|
Hey, since yesterday evening I've completely revised the menu as well as the text engine. The interfaces did not change. The changes in the menu: - New fonts - see attachment (please extract within your craft dir) - Completely revised the implementation of the menu items - code is more elegant - Added the menus "Start SP Game" and "Start MP Game" for testing purposes - Added the ability to menu items to receive input To test the last new thing, select "Start MP Game", select "Host:", hit enter, type in the host, hit enter. Even the backspace works ;) The following things changed in the text engine: - Completely revised parsing of the configs - Added the ability to load all fonts from DATADIR/fonts.zip Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Martin W. <meh...@we...> - 2004-05-22 07:59:22
|
Hey, Arne Rempke wrote: >> I don't think so. Perhaps there is a missunderstanding: if I interpreted >> your code in the right way you support putting tilesets into zip files. >> What I meant was moving the whole directory tiles to tiles.zip . Only to >> move tilesets to zip files still results IMO in too many files. > > > It is also possible to do that. The code takes all files in our > share/tiles directory, and loads all tilesets that are saved directly > to that folder. Then it walks through all the zipfiles in the > directory and tries to load all tilesets from each zipfile. > So it is your choice, wheather to put all tiles into one (huge) > zipfile, or all tilesets for e.g. "greenplanet" into one zipfile, or > each tileset into its own zipfile, or completely do it without > compression, that means you can also save all files directly into the > folder. Of course, you can also combine these possibilities. But putting all tiles in [...]/share/craft/tiles.zip does not work! It's not very suggestive to name it [...]/share/craft/tiles/tiles.zip . The other options you mentioned were not tested by me. Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Arne R. <arn...@gm...> - 2004-05-22 07:32:49
|
Hi, >>Zipfile support for tiles is working. > > > I don't think so. Perhaps there is a missunderstanding: if I interpreted > your code in the right way you support putting tilesets into zip files. > What I meant was moving the whole directory tiles to tiles.zip . Only to > move tilesets to zip files still results IMO in too many files. It is also possible to do that. The code takes all files in our share/tiles directory, and loads all tilesets that are saved directly to that folder. Then it walks through all the zipfiles in the directory and tries to load all tilesets from each zipfile. So it is your choice, wheather to put all tiles into one (huge) zipfile, or all tilesets for e.g. "greenplanet" into one zipfile, or each tileset into its own zipfile, or completely do it without compression, that means you can also save all files directly into the folder. Of course, you can also combine these possibilities. cya arne |
From: Martin W. <meh...@we...> - 2004-05-21 21:47:10
|
Hey, Arne Rempke wrote: > [...] > Great! > But... your isSupportedImage() should check the length of the filename > before segfaulting... ;) Sry, haven't thought of files like '.' or '..' ;) You can remove your checking code now. > And... your extractImage() should set the colorkey, like > video->loadImage() does. >> So I would recommend to put each >> >> - the fonts >> - the units >> - the tiles >> - the maps? >> >> into a zip file. > > Zipfile support for tiles is working. I don't think so. Perhaps there is a missunderstanding: if I interpreted your code in the right way you support putting tilesets into zip files. What I meant was moving the whole directory tiles to tiles.zip . Only to move tilesets to zip files still results IMO in too many files. Regards, - Martin PS: I've just committed CHANGELOG revision 1.111 ;D -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Arne R. <arn...@gm...> - 2004-05-21 19:41:57
|
Hi, > After hours of debugging I'm very proud of announcing the first fully > usable zip implementation! Due to the very helpful link of Arne I've > implemented that files extracted to memory can be loaded into a surface. > I'll give you an example code so that you get an overview how to use CZip: > > --- > > #include "zipwrapper.hpp" > > // ... > > string zipfile = string(DATADIR) + "/test.zip"; > vector< string > files = classes->zip->list(zipfile); > for(unsigned int i = 0; i < files.size(); i++) { > if(classes->zip->isSupportedImage(files[i]) { // file is an image > SDL_Surface *surface = classes->zip->extractImage(zipfile, files[i]); > int handler = classes->video->pushSurface(surface); > } > else { // file is a textfile > string content = classes->zip->extractTxt(zipfile, files[i]); > } > } > > --- Great! But... your isSupportedImage() should check the length of the filename before segfaulting... ;) And... your extractImage() should set the colorkey, like video->loadImage() does. > As I said above this is only an overview to demonstrate how all the > functions work. In many cases you do not need to use such code. > > So I would recommend to put each > > - the fonts > - the units > - the tiles > - the maps? > > into a zip file. Zipfile support for tiles is working. cya arne |
From: Martin W. <meh...@we...> - 2004-05-21 16:37:54
|
Hey, Martin Wegner wrote: >I saw that example with zzip in the docs of zziplib, too. But my problem >was that we decided to support as much image types as possible using >SDL_image. SDL rwops seemed only to be available for BMPs. Foremost, >with a closer look at /usr/include/SDL/SDL_image.h I was able to >determine that SDL_image also supports rwops. I'll implement it now. > > > After hours of debugging I'm very proud of announcing the first fully usable zip implementation! Due to the very helpful link of Arne I've implemented that files extracted to memory can be loaded into a surface. I'll give you an example code so that you get an overview how to use CZip: --- #include "zipwrapper.hpp" // ... string zipfile = string(DATADIR) + "/test.zip"; vector< string > files = classes->zip->list(zipfile); for(unsigned int i = 0; i < files.size(); i++) { if(classes->zip->isSupportedImage(files[i]) { // file is an image SDL_Surface *surface = classes->zip->extractImage(zipfile, files[i]); int handler = classes->video->pushSurface(surface); } else { // file is a textfile string content = classes->zip->extractTxt(zipfile, files[i]); } } --- As I said above this is only an overview to demonstrate how all the functions work. In many cases you do not need to use such code. So I would recommend to put each - the fonts - the units - the tiles - the maps? into a zip file. >[...] > > Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Martin W. <meh...@we...> - 2004-05-21 13:58:29
|
Hey, Arne Rempke wrote: >> Yes, I thought that, too. But SDL or SDL_image do not have the abilitiy >> to load an image from a char * or so. The loading functions of both libs >> need a filename to be given. So I see no other way than loading a file >> and the deleting the file. > > > I just found this: http://www.kekkai.org/roger/sdl/rwops/rwops.html > Seems to be exactly what we need. I saw that example with zzip in the docs of zziplib, too. But my problem was that we decided to support as much image types as possible using SDL_image. SDL rwops seemed only to be available for BMPs. Foremost, with a closer look at /usr/include/SDL/SDL_image.h I was able to determine that SDL_image also supports rwops. I'll implement it now. To my first question I've also found an answer in the meantime: a function who deletes a file: --- #include <cstdio> remove("file.ext"); --- Thanks for that link ... Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
From: Arne R. <arn...@gm...> - 2004-05-21 12:44:39
|
Hi, > Yes, I thought that, too. But SDL or SDL_image do not have the abilitiy > to load an image from a char * or so. The loading functions of both libs > need a filename to be given. So I see no other way than loading a file > and the deleting the file. I just found this: http://www.kekkai.org/roger/sdl/rwops/rwops.html Seems to be exactly what we need. cya arne |