MaxCoderz
http://maxcoderz.org/forum/

Progress thread for original version (2006)
http://maxcoderz.org/forum/viewtopic.php?f=38&t=1880
Page 7 of 9

Author:  tr1p1ea [ Thu 20 Jul, 2006 1:11 pm ]
Post subject: 

I think its just fine how it is ... you wont really notice nor concerntrate on the sky 'that' much.

Author:  kalan_vod [ Thu 20 Jul, 2006 3:43 pm ]
Post subject: 

But it does look GG!

Author:  benryves [ Thu 20 Jul, 2006 3:50 pm ]
Post subject: 

GG? Like a horse?

Author:  kalan_vod [ Thu 20 Jul, 2006 4:42 pm ]
Post subject: 

Good God, sorry for the lingo. Still looks amazing.

Author:  benryves [ Thu 20 Jul, 2006 4:47 pm ]
Post subject: 

Hehe, not come across that one before :)

One thing I could do, if I made the sky a bit taller, would be to add y-shearing so you could look up and down a little. Not sure if it's entirely worth it, though.

Author:  coelurus [ Thu 20 Jul, 2006 5:59 pm ]
Post subject: 

Details regarding the sky is of minor importance in a moment when reasonable performance is tripping very close to the edge :)

Author:  CompWiz [ Thu 20 Jul, 2006 7:18 pm ]
Post subject: 

yeah, the sky looks fine as it is. Don't sacrafice performance to make it a little better. This is a calculator, not a powerful gaming rig that can play games with all the graphics options turned on. Concentrate on making something that looks decent and runs fast. It won't be very fun to play if it looks amazing but runs at like 3 seconds per frame. You do have a great engine though, and you are great at programming. Maybe you can find a way to have more eye candy along with good speed. But speed is important, more so than eye-candy. :)

Author:  thegamefreak0134 [ Thu 20 Jul, 2006 9:10 pm ]
Post subject: 

Wow, this looks so much better than the BASIC engine I worked on. good job! Can't wait to see an actual game in it.

Author:  DarkAuron [ Thu 20 Jul, 2006 11:31 pm ]
Post subject: 

Damn ben you're fantastic. 3D fever indeed!

Author:  katmaster [ Sat 22 Jul, 2006 1:34 am ]
Post subject: 

Hardcore.

Author:  the_unknown_one [ Sat 22 Jul, 2006 7:57 am ]
Post subject: 

Who's da man? Ben's da man!

Author:  Tnm [ Mon 24 Jul, 2006 11:58 pm ]
Post subject: 

Hmm, why do you use grayscale? I mean, you could just make the walls stripped or "chessboarded".
I really loved Glasscar 3d, it was so cool.
Good luck on this project.

Author:  benryves [ Wed 26 Jul, 2006 9:35 am ]
Post subject: 

The greyscale effect is optional (adds about 8 lines of code, only runs once per frame and can be disabled with a single switch in the engine package's Settings.inc file.

Image

Anyway, I've started throwing together a very primitive level editor. (GDI+)

Image

Insert inserts a new vertex at the mouse location; delete removes the closest vertex. Point at a vertex, hold W, move to another vertex and release W to insert a new wall. (Single-sided, hold shift at the same time to add a double-sided wall). Use D to remove walls in the same way. That sort of thing.

The two different types of wall are represented with white lines (single-sided) and grey lines (double-sided). There are therefore 9 different sectors in the above image.

Imagine that the walls have been kept simple (fixed floor/ceiling heights, single segment) and can have one of 6 different 'colours' - from 0 (invisible/transparent) to 1 (white) through to 3 (50% grey) and finally 5 (black).

Therefore, for the sake of simplicity, assume that all of the double-sided grey walls in the above screenshot are invisible. The room in the south-west of the screenshot is an octogonal room with a doorway in the eastern wall and a square pillar in the middle.

The four double-sided walls in this south-western room are not redundant. You will notice that the level has been cut up into convex sectors. This has one small advantage - it reduces the number of walls that will need to be sorted, as I only need to sort entire sectors for occlusion purposes.

Also, I can see that I can get some sort of portal*-based system up and running. Suppose I use the editor to create this:

Image

If I was to start in the left sector, I would go through and draw each wall. I'd hit the double-sided wall at some point, and know that after this sector I'd have to move into the sector in the middle. After that sector, I'd know that I'd have to move to the sector to the right. With me so far?

Let's do something radical and make that central sector a door, and close it (move the ceiling height down to meet the floor height). This time, when I move through the sectors, I'll hit this sector and see that it's closed. No matter, say I - rather than carry on walking through the sectors, I stop at that point.

By liberally sprinkling a world with doors, and keeping them shut most of the time, you can cut out a fair chunk of geometry. :)

I cannot think of the best way to handle sorting. I don't think I can just use the order in which I wander through the sectors - imagine this:

Image

Imagine you're in the north 'triangle' and looking south. As you can see, you need to travel through more sectors to get to the larger rectangular room than the south triangular room - and using that for sorting is just wrong.

One potential workaround I can think of is that each sector has a visibility list - a list of in which order sectors appear (in front->back order - else we wouldn't be able to take advantage of portals). Problems; MASSIVE amount of data that grows exponentially with each added sector! From what I can also tell, that also seems a precomputed BSP list, done per sector (rather than work out which side of the split to follow each branch, it's already calculated for us). On the other side, this can also be used to calculate (through some nifty ray/plane intersection algorithm) which sectors will NEVER be visible from a particular sector... Hmm. I'm not afraid of 'wasting' RAM with gigantic tables - if we assume a smallish, plain level of 50 sectors, each sector would need a list of at most 49 other sectors. 49*50*2=4900B - not actually too bad. :\

(Bah) Just realised that would not work (precomputed sorting based on sectors) at all.

Image

Let's say the red line is your 'view' (not a wall, quick and dirty diagram). It intersects the front of two walls, so it appears that the sort should go north->east->west sectors. However, imagine I move to the other side of the sector and look the same way (mirror the diagram, basically). Now the order goes north->west->east, and I'm still in the same sector :( Do I just clump all the sectors together and sort them all together based on the distance to the central (average) coordinate of each and the camera? (Not fast!)

It's still not entirely a bad thing, as the list could still be used to roughly sort the sectors (some sorting algorithms work well on nearly-already sorted data, even bubble sort). Even then, the information of which sectors are visible/entirely invisible could still be used.

Thoughts?

---
*I hope that's the correct word.

Author:  coelurus [ Wed 26 Jul, 2006 11:04 am ]
Post subject: 

I dunno what restrictions the editor puts on sectors, but a centroid sort will not handle all possible cases:

Code:
 _____________
|             |
|            *| <- Camera
|...._.....___|
|   | |   |
| x | |   |
|___| |   |
      |   |
      | x |
      |   |
      |   |
      |   |
      |___|


The left sector is closer than the right according to the centroids. It feels a little stupid to pose sector restrictions on mappers and having more vertices/walls isn't very efficient I guess.

Gosh I'm glad I never got this far with z80 :D I'll give the problem a thought though.

EDIT: What about sorting by centroid of the portal/double-wall? I've forgot about a lot about sorting, but bubble sort shouldn't be too bad with the few sectors that will be in play. Linear or shell sort maybe?

EDIT 2: There's a problem with portal-sorting if you allow shallow angles inside the sectors, if you go with the prism-brush idea, it'd probably work (I don't know enough topology-maths to proove it :P ).

Author:  benryves [ Wed 26 Jul, 2006 11:51 am ]
Post subject: 

coelurus wrote:
I dunno what restrictions the editor puts on sectors, but a centroid sort will not handle all possible cases
Aha, true. The only 'restriction' is that sectors are convex.

Quote:
Gosh I'm glad I never got this far with z80 :D I'll give the problem a thought though.
Lucky you ;) Thanks for any help.

Quote:
EDIT 2: There's a problem with portal-sorting if you allow shallow angles inside the sectors, if you go with the prism-brush idea, it'd probably work (I don't know enough topology-maths to proove it :P ).
I'm still not too hot on understanding the prism-brush idea :\

At the end of the day, I'll probably have to sort all visible walls anyway - to put sprites in the right place. Just a case of keeping things efficient.

Page 7 of 9 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/