Ah... dont forget the shadows at you character feet. Very easy. Just render th graphics in a single black color but half height of your sprite. Yo may displace each line a little to the left or right in order to create a longer shadow. Render the shadow, then render the image. Nice effect.
Luck!
Guimo
Isometric Interaction, Look/Feel Concepts (warning: large images)
Hi, just wrote this post in another forum/thread and I recalled this one. So I send it here again, maybe its helpful.
-----------------------------------------------------------------
The idea is this:
a. All the light computations are done in 'world' space. In that space you use floating point coordinates. If you are using tiles your tiles will be square in this world space. It doen't matter if your game is isometric. World space is a top view of your game so they should be squares. If your engine is top view... it will be easier.
b. Select all the light emmitters that may create some king of illumination in your scene. Computations are heavy, so the more lights in scene, the slower it will be so use lights carefully.
c. Select all corners of the tiles and fill the in your light buffer. The light buffer is just a float 2D array with the dimensions of the viewable area. (say 10*10, 20*20 or anything. This array will hold the light contributions for each corner of each tile. In 2d apps this corner-light-buffer only requires a floating point number going from 0 to 1 (or any other limits you consider). In 3D based apps you can set each point to 3 floats in order to hold RGB light contributions. At the beginning, each float should be set to the value of the ambient light (usually 0 for a dark place).
d. For each corner compute the light contribution from each light affecting the scene (as you see, more lights, more computations). You may exclude many lights affecting a point by using a simple circle test or square test. Many optimizations available here.
d.1. In case you want more real light, more computations are required. Make a selection of any opaque objects currently in your view area. Opaque objects are those that you consider may block light like columns, doors or walls. Then, before processing the lights (as in d), make a subselection of opaque objects that are near each light. The same opaque object may be associated to more than one light depending the radius of the light. When you have these subgroups, each time you compute the light contribution to a point, you must check the line of light from the light source to the target point. If any opaque object is in the line, the light is considered blocked.
e. When all the process in c is finished, you have filled your light buffer. Lower values mean dark places. These values should be between 0 and 1. The average value of 4 corners is the overall color of the tile in case of 2D. In case of 3D just use the colors of each corner in orderand let the card interpolate the values for a nice shade effect.
f. Once you render the tiles, the objects in the scene can use the light information so they can be rendered lighter or darker.
-------------------------------------------------------------------------
Luck!
Guimo
-----------------------------------------------------------------
The idea is this:
a. All the light computations are done in 'world' space. In that space you use floating point coordinates. If you are using tiles your tiles will be square in this world space. It doen't matter if your game is isometric. World space is a top view of your game so they should be squares. If your engine is top view... it will be easier.
b. Select all the light emmitters that may create some king of illumination in your scene. Computations are heavy, so the more lights in scene, the slower it will be so use lights carefully.
c. Select all corners of the tiles and fill the in your light buffer. The light buffer is just a float 2D array with the dimensions of the viewable area. (say 10*10, 20*20 or anything. This array will hold the light contributions for each corner of each tile. In 2d apps this corner-light-buffer only requires a floating point number going from 0 to 1 (or any other limits you consider). In 3D based apps you can set each point to 3 floats in order to hold RGB light contributions. At the beginning, each float should be set to the value of the ambient light (usually 0 for a dark place).
d. For each corner compute the light contribution from each light affecting the scene (as you see, more lights, more computations). You may exclude many lights affecting a point by using a simple circle test or square test. Many optimizations available here.
d.1. In case you want more real light, more computations are required. Make a selection of any opaque objects currently in your view area. Opaque objects are those that you consider may block light like columns, doors or walls. Then, before processing the lights (as in d), make a subselection of opaque objects that are near each light. The same opaque object may be associated to more than one light depending the radius of the light. When you have these subgroups, each time you compute the light contribution to a point, you must check the line of light from the light source to the target point. If any opaque object is in the line, the light is considered blocked.
e. When all the process in c is finished, you have filled your light buffer. Lower values mean dark places. These values should be between 0 and 1. The average value of 4 corners is the overall color of the tile in case of 2D. In case of 3D just use the colors of each corner in orderand let the card interpolate the values for a nice shade effect.
f. Once you render the tiles, the objects in the scene can use the light information so they can be rendered lighter or darker.
-------------------------------------------------------------------------
Luck!
Guimo
Author
stormrunner:
thankfully :-) 12 year old girls arnt our target market :-D
but, thanks for the input :-)
Tom:
alot of the features you mentioned, we dont have the power to do, thanks for the comments though.
VertexNormal:
we've tried to do a little bit of that, i made a new cobblestone texture last night, that isnt so repetitive, and has an edge set, so i think it helps things, but i like your sugestion of making a bunch of 'detail tiles' basically like cracks and blood and etc. and then having us just go crazy with them, we'll probably do that at the start of the beta phase.
Guimo:
we dont have full access to 3D proccessing power, due to the fact that our game can be run on standard 2D api's
also, your lighting routine that you explained is esentially what we now use.
Hopefully, our assumptions are correct, in that these 'fair' graphics will be enough to get across the visual aspect of our story.
we dont tend to put alot of weight into graphics, mainly because the imagination, when properly massaged, tends to make things out to be more than they are (consider 320x240 old-school games).
so, we are relying on gameplay to take it home for us :-D
This has given me alot to go on, if there are any more comments feel free to make them, but please try to avoid re-iteration of other recomendations (i know, it's hard :-D)
thankfully :-) 12 year old girls arnt our target market :-D
but, thanks for the input :-)
Tom:
alot of the features you mentioned, we dont have the power to do, thanks for the comments though.
VertexNormal:
we've tried to do a little bit of that, i made a new cobblestone texture last night, that isnt so repetitive, and has an edge set, so i think it helps things, but i like your sugestion of making a bunch of 'detail tiles' basically like cracks and blood and etc. and then having us just go crazy with them, we'll probably do that at the start of the beta phase.
Guimo:
we dont have full access to 3D proccessing power, due to the fact that our game can be run on standard 2D api's
also, your lighting routine that you explained is esentially what we now use.
Hopefully, our assumptions are correct, in that these 'fair' graphics will be enough to get across the visual aspect of our story.
we dont tend to put alot of weight into graphics, mainly because the imagination, when properly massaged, tends to make things out to be more than they are (consider 320x240 old-school games).
so, we are relying on gameplay to take it home for us :-D
This has given me alot to go on, if there are any more comments feel free to make them, but please try to avoid re-iteration of other recomendations (i know, it's hard :-D)
Quote:Original post by EDI
stormrunner:
thankfully :-) 12 year old girls arnt our target market :-D
but, thanks for the input :-)
It's too bad, because that's one 12yo that's on the ball.
I wouldn't dismiss the 12 yr. old girl market out of hand just yet. If the goal of a game is suspension of disbelief for a brief time, then you usually can't find a better target than children. They can suspend disbelief at the drop of a hat. If they don't find a game plausible, then it might be a good idea to know the reasons why, and to work on them. In fact, as a direct result of this thread I am considering making my various nieces and nephews integral parts of my testing network. I can't think of a better group of people to give me feedback on the 'intangibles' of making a game feel right. [grin]
First off, great work! Other than what has been already noted. The thing that strikes me as being the worst problem is, everything seems too sterile. All of the walls, floors, items, look brand new. Where are the deformations, dust, dirt, cobwebs. You know, the stuff to offset the "new" look. I know it has been mentioned but aside from that I think everything else is minor.
Just my opinion. Great work.
Just my opinion. Great work.
Author
Quote:Original post by VertexNormal
I wouldn't dismiss the 12 yr. old girl market out of hand just yet.
Chances are, the content of our game wont be suitable for 12 year olds, girls or guys. language and blood and horror alone will probably be a factor that makes it at 17+ game 'offically'
The main issue that the graphics look as they do is because they were done by a programmer *points to himself* and lack certain 'style' that 'artists' convey in thier work. chances are you wont see much of that in our game, for a few good reasons.
1. im the primary artist, but we have somone who is redoing the characters
2. it is not all that important to the story, focusing on making the graphics perfect probably isnt where our time should be spent *rather gameplay, dialogue, story, should be*
3. we arnt relying on graphics to make this game great, it is meant to be played by the 'casual' classic adventure gamer.
4. we are relying on audio (the soundtrack is great, IMHO) to set the tone of things and convey emotion.
I guess, you can think of our game, like a book without pictures *or very few* for those who invest the time in reading it, it will be a great experience, and for those who wont due to judging it by it's cover, then that's okay too =)
A gamer, who today would not play Monkey Island 1, because he claims it's graphics make the game no good, is as wrong today as he would have been when it was released. just some food for thought :-)
hey Ray,
for fog, couldnt you simply just render a quad with transparency over the entire scene? then have it animate, maybe change alpha values, etc. ?
for fog, couldnt you simply just render a quad with transparency over the entire scene? then have it animate, maybe change alpha values, etc. ?
Quote:Original post by graveyard filla
hey Ray,
for fog, couldnt you simply just render a quad with transparency over the entire scene? then have it animate, maybe change alpha values, etc. ?
Yeah that's what we discussed doing intially as well, but since we changed our render engine from SDL to OpenGL think we're going to be using OpenGL to render our fog instead.
i dont really think its possible to use a 3d API to render 2d fog. the same goes for lighting and all that stuff - in 2d, you have to fake it (e.g. do it by "hand" like with a 2d API). i could be wrong though.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
