Submit
In response to build or borrow?
0684f9d33f52fa189aad7ac9e8c87510
0
baldurk 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
0684f9d33f52fa189aad7ac9e8c87510
0
baldurk 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.

In response to davepermen's Adventures
0684f9d33f52fa189aad7ac9e8c87510
0
baldurk 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
590e8bdac8129bd87b188df15e62d0e5
0
CyraX 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?
91fcffbb41940d7cf8d1dd7696095948
0
vinmar 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
F7a4a748ecf664f189bb704a660b3573
0
anubis 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
F7a4a748ecf664f189bb704a660b3573
0
anubis 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
6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 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
6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 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;

FileLoaders fileLoaders;
fileLoaders["bmp"] = &loadBMP;

File* loadFile(std::string fileName) {
  std::string extension = fileName.substr(fileName.find_last_of('.')+1);
  FileLoaders::const_iterator found = fileLoaders.find(extension);
  assert(found != fileLoaders.end());
  return found->second(fileName);
}

something like this?

In response to davepermen's Adventures
6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 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
F7a4a748ecf664f189bb704a660b3573
0
anubis 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
6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 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.

In response to davepermen's Adventures
F7a4a748ecf664f189bb704a660b3573
0
anubis 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
0684f9d33f52fa189aad7ac9e8c87510
0
baldurk 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.

In response to Actual Game Developing
6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Apr 24, 2003 at 12:20

i think skeletons are great for spaceship like models. think of bigger things, that have robot-like arms, think of space-stations, that can brake their connection-arms, and all the stuff. some rigid-body physics, IK, skeletons. thats what at least _could_ get useful:D

In response to Actual Game Developing
590e8bdac8129bd87b188df15e62d0e5
0
CyraX 101 Apr 24, 2003 at 12:16

Pardon me for saying MD3 - I said that in the context of a GENERAL game. NOT a space sim.
In a space sim we need little (or no) animation. Whatever animation is required could be provided by shaders or animated textures :D - foolish.
What are the possible animations?
- Flame
- Burning
- Fragmenting of the aircraft.
- Hmmm maybe the pistons pumping from the engines - This might be needing an MD3 kinda model.

I am not really sure about “our own” format as of now. I would suggest that we load ANY model. Let us evolve our own formats over the time.

In response to Actual Game Developing
8e228221453de890daa003b067fbb84a
0
fringe 101 Apr 24, 2003 at 08:53

Sorry I am being a little vague as always :)) The timming thing I was thinking about ti some sort of clock/performance timer to do frame rate independent movement etc. I know it is easy towrite and in fact I have an object which we can use but I thought I should mention it.

fringe

In response to Actual Game Developing
Fdbdc4176840d77fe6a8deca457595ab
0
dk 158 Apr 24, 2003 at 05:21

we can also make are own file format where we include only the stuff we want…since, as baldurk mentioned, we won’t need and keyframe animation.

Also, about a model loader. We could have a simple one for the purpose of loading, viewing, converting, etc… But at this stage its not that critical.

As for an image loader, I don’t see a great use for it. I believe using TGA, BMP, or PNG is good enough. We won’t need our own file format for that.

fringe: what do you exactly mean by a “timing thing”?

In response to Actual Game Developing
8e228221453de890daa003b067fbb84a
0
fringe 101 Apr 23, 2003 at 20:31

I guess we don’t need all the complexity of a model loader, but it will be useful for projects in the future and if we have it for general use we can make a common interface that will be standard for other stuff in the future,

fringe

In response to Actual Game Developing
0684f9d33f52fa189aad7ac9e8c87510
0
baldurk 101 Apr 23, 2003 at 17:13

I’d take a minute to consider the game type - space sim. Do we really need the features provided in an MD3 file? seperate files, linked together to provide ease of animation. Although that’s useful, why would we even need simple animation in this game. The model would be static and simply moved by the engine.

In response to Actual Game Developing
C24eb7e6aaefba78b94c831ddc7b4d0b
0
donBerto 101 Apr 23, 2003 at 15:30

agreed.

md3 - second vote.

:yes:

In response to Actual Game Developing
590e8bdac8129bd87b188df15e62d0e5
0
CyraX 101 Apr 23, 2003 at 13:22

MD3 plz.
GMAX + Tempest.
MD3 may be the BEST known model.

In response to Actual Game Developing
0684f9d33f52fa189aad7ac9e8c87510
0
baldurk 101 Apr 22, 2003 at 17:23

ms3d models are good, very simple but has everything we need.

In response to Actual Game Developing
91fcffbb41940d7cf8d1dd7696095948
0
vinmar 101 Apr 22, 2003 at 16:08

I like milkshape ms3d models. The ms3d loader on NeHe works well, and milkshape is easy to get hold of and use.

In response to Actual Game Developing
8e228221453de890daa003b067fbb84a
0
fringe 101 Apr 22, 2003 at 15:34

OK, so what do we need then to develope this asteroids sorta game. I guess a central idea of stuff needed for the game “engine”. So here is some stuff we should put together or borrow from our group:

a model loader (as flexible as possible)
an image loader
a timing thing
collision detection algorithm
splash screens/demo modes
menus
text renderer of some sort

just a starting list please add more to the board or any idea. Has anyone been reading the thread on HeNe forums about writting a game engine?

fringe

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

Recent Tags

indie × 5
game-development × 5
ios × 3
android × 3
algorithm × 1
effects × 1
physics × 1
iphone × 1
c# × 1
mobile × 1
physics-engines × 1
native × 1
macos × 1
sound × 1
music × 1
networking × 1
testing × 1
multiplayer × 1
design-patterns × 1
game-programming × 1
3d-engine × 1
shaders × 1
cross-platform × 1
gaming × 1
game-industry × 1