Jump to content

  • Log In with Google      Sign In   
  • Create Account

undead

Member Since 19 Dec 2007
Offline Last Active Nov 03 2014 06:54 AM

#4856666 So what do the pros exactly use?

Posted by undead on 02 September 2011 - 04:04 AM


I understand your point and I partly agree but to say "if you want to be an engine programmer don't make an engine" sounds a lot like a zen monk saying "you'll be ready when you'll be ready". :D


Not exactly. The word "engine" is very very abused in game programming. An "engine" is a set of tools and API that allow an "integrator" to put together a game. In order to become good at making engines you need to understand what things make an engine good or bad, and, contrary to naive belief, that hasn't much to do with performances (up to a point).
To become good at designing a clear software interface means being able to avoid things such as making variable XY a public field of class Z when a bogus value of XY could crash the entire game.. this isn't some kind of "magic wisdom" that comes as a gift from above to some lucky developers, it's just sign of experience made by making that same mistake over and over again.. so now you know better and design software in a more robust way.

Every game is an engine.. that's what people mean when they go "make games not engines"... but the difference between a game and an engine is that a game has "computable values": is it finished? does it work? does it crash? is it fun? An "engine" is a never ending tale with no real tangible elements to judge it.

A game becomes and engine when some of its part can be reused.. but what's the point in reusing something that isn't even working in one single game?
I see this mistake over and over on the internet... I will do a game engine that does this this and that and people will use it to make games.. no they won't, unless you prove it's actually able to deliver.

sorry to go a bit OT from your original question but the line I quoted deserved a dedicated answer.

I agree but that looks a lot like what I said:

focusing on a game is great because:
- you understand how to do something.
- you have code working in practice, not in theory
- you learn what to do and (more important) what NOT to do to build a flexible component


:blink:

The only difference is I think "a game isn't an engine". First of all different games require different features and to focus on a game won't automaGically deliver reusable components. Example: a few years ago I wrote an ENGINE for mobile games in java and at that time Nokia Serie40 1.0 dominated the market. Because of size limitations ( 180kb memory on VM and 64kb jar size) I had to strip down the code by taking ugly shortcuts. I had exactly 8 sprites on screen so I created an array with fixed size 8 in the main class then removed the sprite factory and manually loaded them at startup. As of AD 2011 (but also 2005) if you are creating a set of sprites with a new inside a for loop and then you have to take care of them all you have is a sprite class, not an engine. Yes the class can be awesome but still that isn't an engine: it's a sprite class.

To stretch this to the extreme, 100k of spaghetti code can turn out to be an entertaining game, but no way this is even remotely an engine.


#4856428 How to document a game engine + game development?

Posted by undead on 01 September 2011 - 01:32 PM

I am going to contradict my own practices or the common sense but my experience tells me it's more important to focus on good code and to write documents than documenting the source code via doxygen.

As for good code replicate the same patterns as much as possible. i.e. Creating a new texture/material/sound/script should follow a similar mechanism so once people understand how to create an object, they can create what they want regardless of the object type. Use the same syntax, use meaningful variable names, use some kind of notation to distinguish members, parameters, global variables. Nothing special but if the code is bad code doxygen won't make it better.

I use doxygen and last time I generated the documentation for an huge C++ codebase tried to produce an rtf/pdf file and it turned out to be 2000+ pages. So yes, I definitely use doxygen but when things get quite complex it is of no or little use to have tons of (web)pages documenting what every single method does unless you have something pointing at the big picture. A document is good because you can't write a poem at the beginning of each file!

So in the meantime every time I added a significant feature I wrote a few pages about that. Guess what? Now I have a manual... and even if I'm behind the last developments I have a 140 pages user's manual clearly explaining how to use that engine. Also if you are in a small company or even more if you work alone it might be possible to have to stop development for a while. Without proper documents starting again might be a pain.

Third suggestion: write examples for every sigificant feature, comment them and write a brief description of it. This will also help you refactoring or testing single parts of the engine.

So one day you hire somebody or sb is using your technology... well give him the manual+examples and he'll be fine.

Doxygen is a valuable resource when it comes down to have a quick reference for understanding how a class/method has to be used, documents are valuable when it comes down to understand how your technology works.


#4856212 OpenGL 1,2,3,4 general question

Posted by undead on 01 September 2011 - 03:42 AM

OMG you like DX better than GL... Many people in the world of DX (including myself) complained endlessly over features simply removed from the spec without deprecating, consulting or providing support from 7 upwards. OpenGL does provide full easily readable specification, that deprecates and has a wide base of developers, who develop for multiple platforms. Also OpenGL is extremely OOP! Just consider that encapsulation, abstraction, modularity, polymorphism, messaging and inheritance (wikipedias definition of OOP is completely met by OpenGL! Just thought I should point that out

I don't want to start a flame, but defining OpenGL EXTREMELY OOP is optimistic, to say the least.:)

As for removing features yes it can be a pain but it's just a different model.

My pov is every graphic programmer should have at least a basic knowledge of both worlds, then pick up the one he prefers or the one more suitable for a specific project.


#4855852 Vector graphics programming under Dos

Posted by undead on 31 August 2011 - 06:33 AM

Hi,

I'm interested in developing a 2d platform game under Dos operating system with vector graphics not bitmap (pixel).
There were several games back in the days with such graphics like "Another World", "Prince of Persia" and etc.
I'm programming with C language under Windows 3.11 with Visual Studio 1.5 .
I don't know what are the C libraries or framework to implement such graphics and animation.
Any light on this topic would be appreciated.
Thanks in advance.

I'll try not to write a long reply but there's a lot of stuff to consider so I'm sorry if I'll get tedious.

NOTE: I ASSUME YOU WANT TO DO THINGS THE OLD WAY, MEANING THE DOS EMULATOR WILL RUN AT ORGINAL 386/486/PENTIUM CLOCK SPEED.
If you want to use the power of a modern CPU to do things the old way then what I am going to write won't be accurate, performance-wise.


From my pov the toolchain is your first problem. Back at that time none would ever use visual studio to develop a game/demo.

So first question you have to answer is: do I want to setup a toolchain for a game as old as prince of persia or for something as old as doom?
The point being older games were written in real mode and I suggest getting a copy of Borland Turbo C/C++, version 3.0.
Games like doom were written in protected mode with the much more modern watcom compiler.

I remember when I switched from Turbo C 3.0 I started using watcom 10.5 and 11 and except for some linking bug it was ok.

http://en.wikipedia.org/wiki/Turbo_C
http://en.wikipedia.org/wiki/Watcom_C/C%2B%2B_compiler

In brief the difference between real mode and protected mode is:
- real mode can make you access pages via a segment/offset, each offset being exactly 64kb (dos is a 16-bit OS, remember). You are limited to this kind of addressing because that's the way a x86 CPU used to work in 16-bit... real mode addressing in assembly is just ds:si cs:ip ss:sp etc.
- protected mode allows you to create bigger pages, overcoming the 64kb limitation effectively creating pages up to 4GB (actually protected mode is an extension giving you the power of 32-bit CPUs inside a host 16-bit OS like DOS). And here of course the assembly addressing takes advantage of 32-bit indices, esi eip esp etc.

The extender sold with watcom compilers was DOS4GW, a de facto standard at that time for games.
http://en.wikipedia.org/wiki/DOS4GW

The only alternative I know about (and used) was PMODEW, very popular in the demoscene because of its reduced size making it the only viable solution for a scener.
http://en.wikipedia.org/wiki/PMODE

As weird as it sounds, given those alternatives, you have to decide first which resolution you want to target. Three options here
- Standard VGA 320x200 8bit single buffer
- Custom modex VGA 256x256/320x200/320x240/etc 8bit double/triple buffer
- Standard multires VESA up to 24bit

If you plan to use VESA then the only solution is protected mode as any decent VESA resolution goes beyond 64kb so when rendering you have to change the segment. And since 64kb = 65536 bytes switching will occur in the middle of a line. Not easy and not fast.
If you plan to use standard VGA things are simple (320*200 = 64000 less than 64kb) but remember there's only one buffer so you have to synch to your monitor vertical retrace and be very careful about performance because framerate will instantly drop by half everytime you break a performance barrier unless you consider tearing acceptable.
As for modex it's a very tricky way to configure a video card using all 256kb available on standard VGAs and supporting hardware scrolling or double buffering. This was very popular... probably one of the first games using it was epic pinball (epic... yes the guys of unreal engine 3). Even in this case you might need protected mode but the problem with this system is on some resolutions bytes aren't addressed sequentially.
For four buffer that would mean:
byte 0 maps to pixel 0 buffer 0
byte 1 maps to pixel 0 buffer 1
byte 2 maps to pixel 0 buffer 2
byte 3 maps to pixel 0 buffer 3
byte 4 maps to pixel 1 buffer 0

http://en.wikipedia.org/wiki/Mode_X

Also get prepared to do some assembly work... I worked with tasm (turbo assembler) and wasm (watcom assembler) hated masm (microsoft assembler).
I suggest giving a try to NASM if you want to start writing stuff on a standard VGA resolution quick.

http://www.nasm.us/

As a final note to writing to video memory on a VGA using asm in DOS is very simple.

;setup the video mode, saving 13h as a parameter in ax register and call the video mode switch interrupt service (10h)
mov ax,13h
int 10h

;make es segment point at video memory
mov ax,0xa000h
mov es,ax

;reset the offset inside video memory using xor (saves 1 or 2 bytes)
xor di,di

So now you can write or read to video memory. If you want to fill the screen with a color all you need is this

mov al,colornum
mov cx,64000
rep stosb

rep repeats stosb as many times as specified in cx (64000 = 320x200)
stosb copies the content of al (your 8-bit color) into es:di (your video pointer) and adds 1 to di after copy.

Just remember colornum must be in the range 0..255 and the video mode is palettized so the default color list is fixed (you can find the default VGA palette here http://en.wikipedia.org/wiki/File:VGA_palette_with_black_borders.svg ). Palette can be changed via interupts or (better) outptting data to ports.

Hope this was helpful for a start. :)


#4855798 Lighting issue

Posted by undead on 31 August 2011 - 02:50 AM

And this is my problem. I do not want the light to affect the cube if it is outside of it. As you can see, it is very unrealistic that the side walls are visible when the light rays are not supposed to light them.

If the normals are flipped (they point on the inside) then from what I see the results are ok.

Kidsnapper4 clearly shows the top isn't affected because the normals are flipped but the lit face normals are actually pointing at the light.
You need a shadowing system or if you need a quick trick just check if the light is outside the cube. When it's outside just set one parameter of your light equation to zero.


PARTNERS