Sign in to follow this  
EDI

Ethereal Darkness Interactive's The Lost City of Malathedra screenshots + discussion

Recommended Posts

hrm...

while I like the art...it just kind of seems out of place...

and a bit overly complicated for its size.


i think the barrels half under water are very cool..nice effect.

is this a touristy type of pier or a come back in after fishing type of pier.......or go feed the fish type of pier? (other than the boat used in game) how would it be used by the locals?

Share this post


Link to post
Share on other sites
hehe, yeah the barrels under water effect was not easy to do :D

the dock, serves as a small ferry point where small boats can take you back to the mainland.

while i agree it seems a little weird, it serves as additional scenery for two important points in the game (the begining and end of part1), and I belive it works better than having Rebecca just arrive on the shore without any indication of how she got there.


perhaps a 'ferry sign' and some additional 'stuff' on the dock would help set it's role.

Share this post


Link to post
Share on other sites
ok i dont want to step on any toes here....and i know its really bad, i only spent a few minutes on it...but..you'll get the idea

how about something like this?

Share this post


Link to post
Share on other sites
I'm not sure if you are looking for any artistic feedback at this point, but this is the first i've seen of your screenshots.

First of all, I applaud the work you must have put in to this. After looking at all that you've done, I can't help but to comment on the different styles that are going on between the sprite objects, the character and the ground textures. They all feel different, especially the more realistic/3D looking ground.

I would suggest that by creating ground textures that were more simplified and perhaps more stylized, you could tie all three elements together better. It could be that you wanted to make it more noticable that the ground was 3D, I'm not sure. I love what you've done with the buildings and the dock, but the ground is catching my attention way too much and is detracting from the fine work that has been done on those sprites.

In any case, you should be proud of what you have and will accomplish.

~Mike

Share this post


Link to post
Share on other sites
Quote:
Original post by nex7
ok i dont want to step on any toes here....and i know its really bad, i only spent a few minutes on it...but..you'll get the idea

how about something like this?


I do kind of like that better, we might revise it a bit, but for now we're going to let it be for a while.

Thanks for taking the effort to photoshop it.

Share this post


Link to post
Share on other sites
This is our first interior map for Malathedra, and probably the style we're going with, but perhaps some additional tweaks.

This is the interior of Fabricated Fortunes:

Share this post


Link to post
Share on other sites
Quote:
Original post by nex7
that looks fantastic..I like the faded edges..

whats that on the ground there by the trashcan?


Hehehe! I guess you'll have to pick it up to find out! =D

Share this post


Link to post
Share on other sites
I've done a lot to get it sharper, there still may be a few more tricks I can pull. The issue is that to map the pixels 1:1 will _ONLY_ work if the game is run in it's optimal resolution (1024x768), current even if we use that, and offset the pixel centers, there is still blur as the character moves across the screen in varying (between pixel) degrees, we might be able to avoid this by locking positions to pixel boundries, but this might cause notable jumps as the graphics have to choose which pixel to live on.

Share this post


Link to post
Share on other sites
That makes sense; though I don't see why you couldn't force the player to always be drawn at whole pixels. Just round off the float position, or something.

Share this post


Link to post
Share on other sites
well, the main reason why we can't (did some checking) is because drawing characters utilizes the transformation system, this is very helpful for a few reasons.

1. we don't have to manualy scale things in different display modes
2. we get to use the vertex shader (transformation) which means we don't have to lock and unlock the vertex buffer for each draw to reposition it.

The only way to get 'exactly' 1:1 pixels without any cross-pixel (as you move between one pixel and another) filtering, is to draw using 'pre-tranformed verticies' that is, what you draw on the screen is specified in screen coordinets.

this has the 1 benefit of you can draw 1:1 pixel to texel graphics at all times.

but it has many downsides as I noted, currently we are able to simple specify an ortho projection matrix which makes the characters all appear the appropriate size no matter what resolution you use. if we used pre-transformed we would have to manualy lock and set the verticies of the quad to draw the character at the apropriate size.

another one, we use the transformation pipeline to position characters around the screen, we can do this using a simple translation. if we used pre-transformed we would have to manualy lock and set the verticies of the quad to draw the character at the apropriate place.

in short, (again I don't know how much you know about 3D), you cant just 'draw' somthing somewhere without there being a piece of geometry (a quad) for it to be drawn on, and for optimal performance that quad should be kept on the video card, and maipulated by the video card through transformations, instead of manually twidiling the verticies, which will cause a large performance blockage.

now by offseting my projection matrix i've managed to get the graphics /better/ that is most of the time they are 1:1, but if the camera moves to an 'in-between pixel' position the system will have to filter the graphics to show that in-between state.

while in static screen-shots this looks a little blurry, if you catch it in that state, it actually makes the game motion feel a ton smoother, because it is emmulating 'sub-pixel' motion.

all in all I will keep searching for ways to make it better, but at the moment I can't see a way to do it without seriously degrading performance and causing a lot of pixel jumpyness which won't correspond to the 3D terrain.

Share this post


Link to post
Share on other sites
Just a follow-up:

So I went home and tried a theory, which was to change the sampling mode for characters from LINEAR to POINT, in theory this would not allow 'in-between' pixel states from occuring, and indeed it worked.

all of the graphics remained 100% pixel perfect at all times, however, there was a huge downside, which is what I suspected.

The characters (in an effort to remain 1:1 pixel mapped) would appear to jitter around by one pixel as the map appeared to move smoothly. To say this was annoying and suspention of disbelief shattering is to put it mildly =/

So, i attempted to map the terrain to 1:1 pixel boundries also using point sampling, this however didin't seem to work as well mainly because the terrain as a whole, and each induvidual entity do not choose the same way to map since it is dependent on rounding seemingly.

Not to mention the terrain looked absolutely terrible (since it is true 3D), so as the textures were mapped the remained very pixely.

So I think the conclusion is it needs to be one way or another.

1. total 1:1 mapping of terrain and entities (e.g. cant have true 3D terrain)
2. entities need to filter across mid-pixel conditions (3D terrain, but some entities filter as the view moves or they move)

given that 3D terrain is a major feature we obviouslt cant drop it, so I think the view is currently as good as it's going to get (pixel and filter wise), but if I can discover any other tricks I'll surely use them.

on the bright side, the game motion is incredibly smooth, and due to the filtering much smoother than a discreet pixel game could ever be.

Share this post


Link to post
Share on other sites
I ran into this exact same problem with some 2d opengl thing I did. The solution turned out to be to crank the resolution of the sprite textures way up and blur them a little, then use a nearest minification filter. It made them look great, no matter how they were rotated or how off of 1:1 they were.

Never really tested to see what it did to performance though. Never had all that many sprites on the screen, either.

Share this post


Link to post
Share on other sites
Quote:
Original post by EDI
in short, (again I don't know how much you know about 3D), you cant just 'draw' somthing somewhere without there being a piece of geometry (a quad) for it to be drawn on, and for optimal performance that quad should be kept on the video card, and maipulated by the video card through transformations, instead of manually twidiling the verticies, which will cause a large performance blockage.


I'm not certain that's such a huge issue; the overhead of drawing the polygons (the overhead associated with the the actual operation, irregardless of it being a 2-poly quad, or a 1000 poly mesh) will blow away any overheads of using DrawPrimitiveUP or DrawIndexedPrimitiveUP instead of using a pre-loaded VB. We use pre-transformed 2D (XYS_RHW) for all our sprites, clamping to the nearest pixel-center.

You may even find that it's faster, since with a bit of sorting you can draw several quads that uses the same texture in a single operation.

Of course, for your 3D terrain, using VBs and IBs (as you are) is critical for performance.

The game is looking great; good to see that the Indie spirit still lives!

Allan

Share this post


Link to post
Share on other sites
Quote:
Original post by __ODIN__
I'm not certain that's such a huge issue; the overhead of drawing the polygons (the overhead associated with the the actual operation, irregardless of it being a 2-poly quad, or a 1000 poly mesh) will blow away any overheads of using DrawPrimitiveUP or DrawIndexedPrimitiveUP instead of using a pre-loaded VB. We use pre-transformed 2D (XYS_RHW) for all our sprites, clamping to the nearest pixel-center.


currently all of our geometry exists on-card, and never changes except during map-reloads and such.

so, correct me if I am wrong, but the performance of:

for 500 entities
{
- use shader transformation to transform quad
- render quad using DrawIndexedPrimitive
}

is far greater than the performance of:

for 500 entities
{
- lock vertex buffer and fill with appropriate quad data then unlock
- render quad using DrawIndexedPrimitive
}

unless I am somehow wrong, this will CPU limit our game even more.


Quote:
Original post by __ODIN__
Of course, for your 3D terrain, using VBs and IBs (as you are) is critical for performance.


I would say it is critical to keep any resource you're using on-card.

Quote:
Original post by __ODIN__
The game is looking great; good to see that the Indie spirit still lives!


Thanks =)

As for locking vs. transformation, we would still have the discreet vs. smooth problem, wherein the terrain appears to move in sub-pixel increments but the entties only move in discreet units.

Thanks for your input though.

Share this post


Link to post
Share on other sites
Quote:
Original post by Deyja
I ran into this exact same problem with some 2d opengl thing I did. The solution turned out to be to crank the resolution of the sprite textures way up and blur them a little, then use a nearest minification filter. It made them look great, no matter how they were rotated or how off of 1:1 they were.

Never really tested to see what it did to performance though. Never had all that many sprites on the screen, either.


that might work, but as you started to mention, it would be a gross waste of video memory.

on another note, we've shown these screens to various other communities composed of adventure gamers (given that this is an adventure game) and we haven't gotten a single negative comment about the graphics. In fact the worst we've gotten is 'wow it looks much better than Morning's Wrath' lol.

So could this simply be overly sensitive developer-eye?

Keep in mind these gamers are used to 320x200, with sprites that do nearest-neighbor scaling to walk away ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by EDI
currently all of our geometry exists on-card, and never changes except during map-reloads and such.

so, correct me if I am wrong, but the performance of:

for 500 entities
{
- use shader transformation to transform quad
- render quad using DrawIndexedPrimitive
}

is far greater than the performance of:

for 500 entities
{
- lock vertex buffer and fill with appropriate quad data then unlock
- render quad using DrawIndexedPrimitive
}

unless I am somehow wrong, this will CPU limit our game even more.


Well, if all your data exist in tiny VB's of 6 vertices, the fact that they're 'in VRAM' is pretty irrelevant; there is an overhead related to each DrawPrimitive call which will swamp everything else. At that point there's possibly optimization to be found by realtime filling a system RAM array, and rendering it using DrawPrimitiveUP (on the assumption that realtime sorting will allow you to draw >2 triangles per draw-call). DX is just not very good at doing micro-batches, is the key problem.

If possible, I'd run this through PIX and VTUNE.. I suspect you'll find you're burning a lot of CPU doing the DrawPrimitive calls.

Best of luck,

Allan

Share this post


Link to post
Share on other sites
I don't doubt im burning CPU submitting entities, but that is sort of the reality of the situation.

the only way i could optimize it is by batching like-entities that happen to fall together in a particular order (since i have alpha blending on and must sort back to front), again this would only work if i was preparing the VB each time, since otherwise it requires that i have a different transformation matrix for each entity, which i imagine screws up the batch.

you may be right and I'll have to run it through a profiler, but my gut instinct is that if i'm already burning CPU I don't want to do anything to cause me to burn more.

either way for now it's staying like it is, given that we havent gotten any complaints for the adventure gamer communities, and the smoothness in movement it gives is actually quite nice, now that i've wittnessed the discret pixel alternative.

Share this post


Link to post
Share on other sites
You can also combine multiple non animating sprites together in a single huge texture, and then render only parts of that texture..
that way you can render all the geometry of those sprites in one batch.

Also, those trees, are they all using the same sprite?
You can obviously combine those in the same batch too..

If you have large batches of sprites.. beter do vsd on all the sprites in the batch together, and not bother checking visibility for each one individually..
That way you can have one large static batch which you never have to modify.
rendering will be fast enough anyway..

hope this helps (and i'm not telling you stuff that you already know ;))

Share this post


Link to post
Share on other sites
Quote:
Original post by LogicalError
You can also combine multiple non animating sprites together in a single huge texture, and then render only parts of that texture..
that way you can render all the geometry of those sprites in one batch.


Assuming the system has support for this, it can also cause 'bleeding' if the graphics are spaced too close together.

We opted to not allow this because it /really/ had the potential to complicate the workflow.

we rely on using small(ish) managed textures which can be swaped in and out simply if needed.

Quote:

Also, those trees, are they all using the same sprite?
You can obviously combine those in the same batch too..


Two different ones, and no, we can't unless they happen to fall in contiguous order after a back to front sort, because we are using alpha blending.

And again, we can't do this unless we revert to manually filling vertex buffers, which I still think is very poor design compared to using transformations.

Quote:

If you have large batches of sprites.. beter do vsd on all the sprites in the batch together, and not bother checking visibility for each one individually..
That way you can have one large static batch which you never have to modify.
rendering will be fast enough anyway..


vsd?

one large static batch you never have to modify?

do you mean taking all of those trees and putting them into a single vertex buffer?

how the heck would the system determine that? we certainly don't want the hassle of having to determine what goes into what VB manually.

we're not crafting these scenes manually in geometry, it is simply drawing whatever should be drawn, things can enter and leave the scene at will.

Quote:

hope this helps (and i'm not telling you stuff that you already know ;))

[/quote]

I apreciate the input, but most of what you mention seem to be incredibly complex optimizations which would comprimise flexibility and developer ease of use.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this