Who needs splitscreen when you have ONLINE MULTIPLAYER?
Only players are currently synced, everything else is completely clientside. This will also work for local network without problems. The other guy in the video lives about 800km away.
I will put netplay on hold until I have finished the game, though. It would become too much of a mess.

I've been working on a project for College this past semester, last time i spoke about it here was just when we started. Our time is now up and we are getting ready for the presentation now. I thought I'll show you guys some of what we've done:

It's a Team based, third person shooter. We have Controls points, Capture the Flag, Team Deathmatch and a random Soccer game mode. 6 Classes each with 2 weapons and 2 abilities, each ability can be upgraded.
Our art department is meant to do the levels but they didn't have enough time, so most of the maps are mine (including the one shown above). Most of the map textures there i just threw together as well.

We're going to recording a gameplay video soon; so i'll probably show that off too, next week :P.

And while you nerds were arguing about the pros and cons of GIFs, I recorded it with a tool I made earlier today that lets you record GIF's directly off your desktop and upload to an FTP server automagically.

Just thought i'd give a tiny update, for those who remember i posted about being invited to monetize my youtube account, i've created a whole new account with help from my brother and i shall keep you informed whether they will accept our adsense account or will keep it banned!

I can't wait for the autoplay video/animated gif fad to end. It's getting to the point where being able to load the page and scroll down without everything locking up is a small miracle.

I understand your complaint, but people are much more likely to comment and rate if you have something that jumps into their eyes and burrows into their brain.

You can post about some awesome project you've worked on for 2 months, but without an image, you'll get a couple informative's. With several animated images, you'll instead get 30 programming kings, 20 artistics, 8 winner ratings, and people will comment on it for 2 pages.

That's an interesting mix of OO and non-OO programming. Why have the material system return an ID? Why not a Texture class or something?

The texture ID will mostly not be exposed outside the engine, since most things will be handeled in the shader manager, but I should probably implement a texture handle class or something

Which would be totally useless really, since textures are only unloaded when they arent used, so if you do it right the ID will never be invalid, and the non-engine side should probably never be touching raw textures anyways

Edited:

Also, I actually have proper multi-monitor support! Why does nobody actually ever bother writing that when its just 100 lines of code

2nd December 2011
Last edited by ROBO_DONUT; 2nd December 2011 at 09:22PM.
Post #25

Easier to store and sort materials by ID I imagine - You want to batch together identical textures when rendering.

This is true, but I'm wondering if it's worth it with the trade-offs you're forced to make. Generally you want some sort of spatial hierarchy structure to make frustum/occlusion culling viable, so if you're traversing a structure like that it doesn't seem convenient to batch meshes by sorting their texture ids.

You also benefit by sorting front-to-back when rendering opaque objects, since doing so will cause more hidden fragments to fail the depth test and be skipped entirely. I'd be interested to know which optimization is more useful.

This is true, but I'm wondering if it's worth it with the trade-offs you're forced to make. Generally you want some sort of spatial hierarchy structure to make frustum/occlusion culling viable, so if you're traversing a structure like that it doesn't seem convenient to batch meshes by sorting their texture ids.

You also benefit by sorting front-to-back when rendering opaque objects, since doing so will cause more hidden fragments to fail the depth test and be skipped entirely. I'd be interested to know which optimization is more useful.

Wouldn't you want to sort through which objects you _want_ to render, then sort by shader/textureID? I've yet to develop a system like this so you could be right.

Woo, full texture pallet loading and slightly bigger map parsing.
16x16 worked just the same as the 8x8 map, so it should scale to 64x64 fine, but I did notice that it had swapped X and Y of the input map. Hm.
I'm thinking of breaking it up into chunks for the renderer somehow, but I'm not sure how or if this is a good idea.
The best I could come up with was iterating through the walls matching start and end points together to form rooms, then somehow linking them via doors. The problem is I can only think of an O(n^n) style algorithm for calculating that with how the walls are currently stored, which doesn't sound much fun.
Any ideas?

Woo, full texture pallet loading and slightly bigger map parsing.
16x16 worked just the same as the 8x8 map, so it should scale to 64x64 fine, but I did notice that it had swapped X and Y of the input map. Hm.
I'm thinking of breaking it up into chunks for the renderer somehow, but I'm not sure how or if this is a good idea.
The best I could come up with was iterating through the walls matching start and end points together to form rooms, then somehow linking them via doors. The problem is I can only think of an O(n^n) style algorithm for calculating that with how the walls are currently stored, which doesn't sound much fun.
Any ideas?

Uhh input size should have little bearing on the speed you render at. It's a raycaster.