Japanese game source code?

"Sure, it's more time efficient to have a re-usable code base, but I'd rather have code that's low level and to-the-metal than high level with a ridiculous number of functions blanketing the underlying API/hardware"

Fair enough - how is your assembly?
How was the Exception code?

 

Nothing personal but I wouldn't call or consider your code low level. It's just flat and basic. It's not even really optimized in a lot of ways.

I don't mean to be harsh but you keep forcing a coding idea which I don't think you really get and just pick words to fit what you think it is.

=/

 

I haven't looked over the second snippet much, but from the first example I don't see what you mean by this because there is a lot of room for improvement in terms of performance. If you're all about performance then you should ditch superfluous floating point calculations and all divisions, factor your state machines and use jump tables, really minimize the amount of conditional code and consider cache associativity. Also wrapping a lower-level API like DirectDraw and DirectSound would be preferrable to OpenGL and whatever is used for WAV playback.

My definition of low-level I think is also your definition, all of the engine features I mentioned can be implemented in a "to-the-metal" fashion, in fact when you're writing this stuff in C you have to roll your own data structures so what's lower level than that? The features I mentioned are also standard paradigms from console games, running on 1000x less instructions per second so it's not just a matter of ease of reuse or maintainability as it is of runtime functionality/game quailty. There are just times when you need dynamic data structures and in a game context they are 100% analogous to the objects you're avoiding. Think of a bullet-hell shooter, how in the world would you implement one in your current system? Would you hand-manage each bullet's velocity in code? Manually check for thousands of collisions with the player each game tick? Of course not, you write something more clever to let the computer handle it for you, that's not high-level, it's just putting the computer to good use.


I wish I had the time to finish up an example of what I'm talking about but a PC game engine is on the very very back burner.

This is the jist of it:

struct game_object
{
position p;
state s;
};

game_object** obj_list = NULL;

int obj_count = 0;

void spawn_object(position p)
{
game_object* h = malloc(sizeof(game_object));
h->p = p;
h->s = 0;

obj_count++;
obj_list = realloc(obj_list, sizeof(obj_list) * obj_count);
obj_list[obj_count - 1] = h;
}

int main()
{
spawn_object({100,200});
spawn_object({5,32});

int i;

loop:
for (i = 0; i < obj_count; i++) eval_object(obj_list);
goto loop;

return 0;
}

 

Pretty good actually... as long as I stick with VC's inline assembler! :dance:

Well, for starters, I told you it wasn't optimized. Didn't you read what I said earlier? Second, what have I forced on anyone? :shrug: But maybe I should just discontinue arguing/explaining my coding style because I have the feeling that this is going to turn uglier. :gravedigging:

I appreciate your honesty btw.

I said it before and I'll say it again, I know it's not optimized. Before I do that, I just want to get the darn thing working properly. I'll be honest though, I didn't mean for it to evolve into the mess it is now.

Now tbh, even though that's what I prefer, I wouldn't really recommend using DirectDraw so much anymore because simply put, that's just now how the hardware works anymore. I've gotten better speeds from using textured quads (sucks, I know), especially with Direct3D. OpenGL is also much better suited for sprite batching than Direct3D too since I'm not limited to triangle strips/fans and I can sort sprites by texture and what not. The downside is that OpenGL drivers tend to suck for cards that aren't NVIDIA or CAD oriented.

Fair enough. This is well said, so I can't argue with you here. Don't get me wrong, I appreciate everything you all are saying 100%, really. I need to get out of sandbox mode before things become too unmanagable. I had a far better implementation in mind, but I ended up letting it build on a bad foundation with too much hard coded stuff. The thought of "now, how am I going to expand the game for a sequel?" crossed my mind and I see that I'm going to have to change a few things. I prefer a similar arch like what you have presented and I like finding ways to use fewer cycles while still creating a managable code structure.

I think something I should probably do is implement a list of function pointers meant to be executed in a certain order and/or activated and deactivated when necessary. It would be a good idea to get rid of those switch statements and what not, that looks pretty bad. Mike McShaffry (author of Game Coding complete and a part of the Theif programming team) wrote a good chapter on it. I used it and it works pretty good for me. Kinda like this:

struct process_t
{
void (*func)();
unsigned int flags;
// blah blah blah
};

struct process_t* process_list = NULL;
int max_process_count = 0;
int active_processes = 0;

int alloc_process_list(int size)
{
max_process_count = size;
process_list = (struct process_t)malloc(sizeof(struct process_t)*max_process_count);
if(!process_list)
return 0;

return 1;
}

int add_new_process(void (*f), unsigned int flags)
{
int i = 0;

// find an inactive process
if(active_processes>max_process_count)
return -1;

while(i<max_process_count)
{
if(!process_list.func)
{
process_list.func=f;
process_list.flags=flags;
return i;
}
}

return -1;
}

void run_process_list(unsigned int flags)
{
int i = 0;

// assuming the process list was already allocated...
while(i<max_process_count)
{
if(process_list.flags & whatever)
process_list.func();
i++;
}
}

Similar to that, but it was better written from what I remember. Once again, I appreciate everyone's advice. I try not to turn a deaf ear to other advice. Let's just say I'm like the borg... I wish to assimilate you[r code]! ;-)

EDIT: Hopefully my 3D futuristic racing game "CyberCrash" 's source will turn out better. I'm actually using Direct3D and minimal OOP with C++.

 

It depends on what you're doing. DirectDraw isn't guaranteed to be hardware accelerated for stuff residing in video memory anymore, Direct3D of course is. That makes Direct3D great for most games that throw textures into video memory and can manipulate it there.

For a low-level game (getting sick of the term now lol) where you write your own software rasterizer/renderer like an emulator, you're basically just using the API to overwrite part of the video memory/framebuffer with a new completed frame from system memory. If you do it with Direct3D (I presume, not 100% sure) there's more setup needed while the same latency applies in copying the data over.

With Direct3D you do at least get HW-accelerated interpolation, and maybe some decent screen filters could be described with shaders, but neither are very low-level I like to soft-render everything for absolute control and a complete understanding of what's going on, but yeah, under normal circumstances it's not as fast. I guess sometime I'll have to move up to Direct3D to play with HLE since I won't be writing a 3D renderer anytime soon.