In response to Actual Game Developing
0
101 Apr 28, 2003 at 20:36

What ever floats your boat. Im not knowledgable with nix’s yet and I know not there specifications. Im working on a plug-in interface via dll’s – hence the reason I brought it up. And your right on the complexity, you’d have to agree on a set of common standards and redo every dll version when ever a major change was made to the interface where if you use the compiler #ifdef tags changes can be made to all at once.

One last thing I’d like to recomend:
Start the game documentataion. I’ve glanced over a lot of things that have been said and some agreed upon but I cant see any official record of it. I suggest a mod Post an announcement type thread that only the mods can alter that lists everything that HAS been agreed to in a formated easy to read fashion. Don’t let this become another all talk–no walk idea.

In response to Actual Game Developing
0
101 Apr 28, 2003 at 17:13

I’m not really bothered about the image thing. Just playing devils advocate.

Amithran: actually, my opinion is that that would make things a good deal more complex. It would be simple if you can just slot dlls in and out, but remember that you can’t use dlls for anything other than windows. Although there are shared libraries (the same thing) I would have thought it would be easier just to have a common interface, and put the platform specific code in #ifndef / #endif blocks, so that it is all sorted out at compile time. eg.

// Main code:-

OSCode MyOSInterface;

// function calls, but no OS specifc data/variables/types
MyOSInterface.createwindow(foo, bar);
MyOSInterface.dostuff(blah, baz);

// declaration of OSCode (OScode.h?)

#ifdef _WIN32
class OSCode
{
// windows stuff
int createwindow(int width, int height);
}
#elif defined(_unix)
class OSCode
{
// unix/linux stuff
int createwindow(int width, int height);
}
#endif


that way the rest of the code doesn’t (need to) know or care which OSCode we’re using.

In response to Actual Game Developing
0
101 Apr 28, 2003 at 16:51

@baldurk

this isn’t a demand, but I won’t be able to help code if we are only using DX or only using windows code, so it would at least need to support OGL and SDL or whatever.

Sorry for chiming in here a little late, but I wanted to add a few thoughts on the graphics api question I noticed in pages 5 and 6.

I think the best-(not too difficult) thing to do is set up an interface for graphic and window calls. You can use .dll’s to handle the opengl, sdl, dx specific graphic calls. This would limite download size as the user could download the base .exe file and choose what graphic mode to run in and download the specific dll with the correct plugin.

ie.
glInterface.dll
dxInterface.dll
sdlInterface.dll

The windows and linux portability could be addressed using dll plugins as well in the same fasion.

The idea is every function call that would be related to a specific type of api should be wrapped up into a plugin-able interface.
The idea comes from reading the plugin tutorial on (shoot forgot website[im at school] Ill get the address later today).

functions like:
createWindow
resizeWindow
moveWindow
etc. for windows/linux platforms would be interfaced

and
pixel
drawTriangle
etc. would be interfaced with the graphical.dll’s

This would solve the whole problem of protability, as any one who contributes via coding would no longer be limited by graphical api.

In response to Actual Game Developing
0
101 Apr 26, 2003 at 13:00

i think davepermen is right. especially because this is an internet project. every artist that might want to support this project might be used to his own modeller, image format, etc.
sure it’s easy converting into one format but it’s just as easy supporting many file formats.

In response to Actual Game Developing
0
101 Apr 26, 2003 at 10:59

its easy enough to use devil and don’t even bother. just convert to one final format in the end. you can even encript that and all the fancy stuff if you want (i’ll use wavelet from.. mavel or something like that in the final code, but devIL before, as no one supports that mavel format in the editors yet..)

that is USEFUL. just download a freaking model from the net, with some texture in some crappy format, and you can use it.

patchwork artists are very fast at rapid prototyping, but they require that it should be possible to load anything. it just helps everyone.

(integrating devIL is easy)

0
101 Apr 26, 2003 at 10:45

touche!

In response to Actual Game Developing
0
101 Apr 26, 2003 at 10:43

well, even if the artists refuse to conform, it’s easy enough to convert jpgs, etc. into TGA.

In response to build or borrow?
0
101 Apr 26, 2003 at 07:45

vinmar: ditto :lol:

to test, i put null vote. now, it says i’ve already voted. oh well.

:yes:

In response to build or borrow?
0
101 Apr 26, 2003 at 04:01

build

0
101 Apr 26, 2003 at 00:05

baldurk : lol, depending on which part of the uk you’re from you shouldn’t be the one to complain about deformation of the own language :)

In response to Actual Game Developing
0
101 Apr 25, 2003 at 17:58

because it lets artist use existing material, just for testing purposes. they love to test existing stuff. i know that. and explaining them fileformat restrictions for simple testing if something at least looks interesting, then you’ve made something wrong. don’t stand in the way of your artists.

In response to build or borrow?
0
101 Apr 25, 2003 at 17:13

I voted build because I think it could be done easily, and I’d prefer to over getting a pre-built one.

In response to Actual Game Developing
0
101 Apr 25, 2003 at 17:12

hmm, davepermen, why allow the artists to create many image formats and model formats, rather than saying “only TGAs and MS3Ds” from the start. That, I think, would be easier.
Also, with shaders etc. One other problem is that less people would be able to develop/test those paths. I think multiple paths is the best option by far though.

0
101 Apr 25, 2003 at 17:10

that’s really bad german! missing out ichs, endings all over the place

tut tut ;).

In response to Actual Game Developing
0
101 Apr 25, 2003 at 13:46

I accept it - shaders should be supported optionally.
Loading models and textures : Classes that support various formats. We will ONLY load one type of texture. So lets stick to a common format TGA is my vote

In response to build or borrow?
0
101 Apr 25, 2003 at 13:30

I think building our own is a BAD idea, but i want to do it anyway. So i voted BUILD Build build!!!

In response to Actual Game Developing
0
101 Apr 25, 2003 at 08:11

davepermen : ok, i think i get your idea. sounds like the right thnig to do…

In response to Actual Game Developing
0
101 Apr 25, 2003 at 08:06

using a hashmap for supporting different file loaders was something i had in mind. i agree that facilities for loading different types of resources should be seperated.

In response to Actual Game Developing
0
101 Apr 24, 2003 at 20:55

or you want external dll’s for each and every format?

as i said above, i don’t recoment this. bether write an “image loader”, a “mesh loader” and a “music loader” for example, wich can be nothing but a simple devIL wrapper, or what ever. for development thats great. for the final product, replace it with an own format, or with just one format, put the loader for only that format in, and replace all models. the most simple and clean way. clean final product, easy to work with for devteam.

In response to Actual Game Developing
0
101 Apr 24, 2003 at 20:51

@anubis

the nicest would be to write a wrapping layer that would somewhat automate the process of loading files.
like recognizing images by file extension or so.

hm.. i prefer putting a file into each and every loader routine that i have and check if it can load it:D

but, if you want..

typedef std::map<std::string,File* (*loadingRoutine)(const std::string&)> FileLoaders;

std::string extension = fileName.substr(fileName.find_last_of('.')+1);
return found->second(fileName);
}


something like this?

0
101 Apr 24, 2003 at 19:44

ach mir gehts schon wieder soweit gut. bin heut wieder arbeiten gegangen, bin wieder fit und munter. jaja, hätt auch noch mehr picts. vielleich morgen wieder neues aus dem utopia

translation: i’m actually quite fine again, just wen’t to work today, and i’m full of energy and all the blahlbah (i can’t translate word by word!!!). and i would even have more pics, somewhere.. possibly tomorrow there’ll be new ones from the utopia.

we’ll see

grüsse nach rechtrheinland!!!

In response to Actual Game Developing
0
101 Apr 24, 2003 at 17:43

the nicest would be to write a wrapping layer that would somewhat automate the process of loading files.
like recognizing images by file extension or so.

In response to Actual Game Developing
0
101 Apr 24, 2003 at 17:26

the rule is simple (learned from a real gamedev). use simple, existing libraries to make it possible to use as much formats as possible in your engine. helps the artists IMENSE to work. then, for the final package, convert all, drop the generic loaders and plug a specific loader in.

i currently use devil simply plugged in (about 5 lines of code), and replace it by an own format, all data converted in the final product (uses about 300-500kb of dll bull*beep*:D).

looking for something similar for models, but i think i’ll have an own editor.. can’t get around using one of the existing programs, hehe:D simply not WYSIWYG for me.

0
101 Apr 24, 2003 at 17:23

party photos… very cool… i’ll try to get some of mine up

und gute besserung :)

In response to Actual Game Developing
0
101 Apr 24, 2003 at 17:17

I think we should pick one image format, e.g. TGA, and stick with it. It reduces code size and helps understanding.

also, CyraX reminded me that I should point out one thing that I would like to be a main goal - backward compatibility. I would like to see as few extensions being used exclusively (ie, no fallback) and especially no shaders. A hell of a lot of people don’t have shader-compatible cards, and this would leave them out. I’d prefer to write the game in such a way as we can scale it, e.g have LOD or several model files so that people on older machines can still run it smoothly.

CyraX: this isn’t directed at you, I’m just trying to put it out there now.

Welcome to DevMaster, a community-driven game development website of posts and resources!

indie × 4
android × 2
gaming × 2
music × 1
sound × 1
ios × 1
multiplayer × 1
networking × 1
testing × 1
3d-engine × 1