Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Ashaman73

Member Since 10 Nov 2006
Offline Last Active Today, 07:45 AM

#4997481 Looking for feedback on my iOS game level.

Posted by Ashaman73 on 05 November 2012 - 01:57 AM

My two cent. You scene looks promising and you just to take it to the next leve, try to improve on a single aspect each iteration and you will improve the whole scene really quickly.

Start with your weakest point first, which is lighting the scene. As the others have already mentioned, vertex painting is a great way to add some basic, artistic shading. I call it artistic, because you don't want realistic lighting but a more game design centered lighting setup.

This is platformer and I can identify 4 important parts in your scene:
1. the plattform(ground)
2. the background(wall)
3. the separator(ceiling)
4. important game design features (lift)

The plattform is where the player will move on, therefore it needs a lot of attention. The background isn't important and should be used to help visualising the foreground (=player+ground). The separator should be clearly visible, but should not draw a lot of attention and the important game design features should be like a bonefire. Here are a few steps which might be helpful.

(use almost only vertex paint)
A. Tone down the whole scene:
Tone down the whole scene using vertex color (use a dark,brown tone like #401010).

B. Turn the 3 lantern off.
Turn off the 3 lantern to break the monotomy and to highlight the lift (see below).

C. Pimping the background:
Light up the walls around the left two lantern enough to hint a light fall off on the walls, dont touch the ground yet.

D. Pimp the ground:
Light up the whole ground, use a gradient from the wall (dark) to the foreground(light) and increase the light intensity where lantern are turned on (light fall off). Give the vertex paint a yellow/orange touch where the lights are brightest.

E. Pimp the ceiling:
Light up the ceiling (upper bar) only so much, that a clear constrast between wall and ceiling is visible.

F. Pimp the lift:
First you need to lighten the lift itself, you have a very dark texture, use either more metal to light it up or brighter wood. Then make the two lanterns left and right of the lift much brighter than the rest and use them to light the lift. Best to use a little more color in the light to draw more attentention.

When you watch the scene from the right to the left, the lighting should lead your eyes along the ground and finally to the lift.

Good luck :)


#4997465 First Person Melee Games: Why do these games use 1st person instead of 3rd pe...

Posted by Ashaman73 on 05 November 2012 - 12:57 AM

Looking at the games of the last years I wonder if the reason to use 1st/3rd person perspective in an action/shooter game is not more mundane. I think that is it less of a game design decision and more of a visual one.

If you use a 3rd person perspective you see the player and have the option to show off all the nice animations for some special attacks, climbing, taking a look at the breathtaking environment, it feels better on consoles etc. , on the other hand, a first person perspective is not in need of most of these, making it cheaper to produce.

Here're some modern games and similar older games:
Assassins Creed (3rd) vs Thief (1st)
GoW (3rd) vs Doom (1st)
Deadspace(3rd) vs SystemShock(1st)


#4997202 8800GTX and only 150 Particles before lagging? Help. =)

Posted by Ashaman73 on 04 November 2012 - 09:44 AM

Without particles it feels like i am moving "fast".

We need some numbers. Get the free version of fraps to display the FPS at least or best to incorporate some kind of time measurement in your code.

Do you send the particles in a single batch to the GPU or are you using a batch for each particle ? The latter will most likely slow down your performance even for only 1150 particles. An other issue would be to paint 1150 large particles, which could result in an huge overdraw rate, an other reason for a slow down.

Best to provide some more data and a screenshot.


#4996512 Feedback on my Game Idea (randomly generated dungeon RPG)

Posted by Ashaman73 on 02 November 2012 - 06:27 AM

In a broader sense, almost anything can have randomness programmed into it.

I would be more careful about using this term in context with procedural content generation. For sure, adding some "x*random()" in your code isn't the big deal, but generating random content, is often less random then you might think.

Take a look out of the window, either looking at a skyline or nature scene, in both cases you are not really looking at randomness. Even nature follows rules and these rules are extremely complex and have huge amount of parameters. The easy part is to make a parameter random, the incredible hard part is to delevop a system which generates something meaningful und useful out of these parameters.

I'm using procedural content generation in my game, but only a small part is really random. At least I've learned that random procedural content geneartion often produce ugly, unlogical, incomprehensible,boring, unbalanced, and eventually unplayable content. I've increased the scripted part of the content generation continuously in the last few years to beat useless content generation.

This depends heavily on the rule set in which content lives. I.e. a rogue-like game have not many or hard rules when it comes down to visual representation, therefore generating content which is visual representable in a rogue-like game is quite easy. When you consider the visual representation of an game like gears of war, PGC is no longer feasable (beyond maybe terrain generation).

The next generation of consoles and AAA titles will try to beat visual presention, physics and AI of the current gen, introducing more rules than any game in the last decade. The effect for PCG will be crushing.

Which modern game comes in mind when you think about PCG in game ? When you now think of minecraft, you just need to look at the level of abstraction and rule limitation to see what it needs to use PCG in games.


#4996480 is Ragnarok's art Pixel Art ?

Posted by Ashaman73 on 02 November 2012 - 03:39 AM

Pixel art is not a clearly defined term. IMHO pixel art is the creation process and not the final product. Like oil painting, you can create, or better say fake, the look of a oil painting with digital tools, but an oil painting is only an oil painting if it is painting with the right technique (oil paints).

Pixel art is from an era where resources were limited, especially resolution and colors. When painting images for small resolutions (16x16 or 32x32) you start adjusting single pixels to get the image right. You just can't use photoshop and a brush to paint them, you will need to modify pixel for pixel, which is where the name of pixel art is coming from. Therefore many pixel artists consider MS paint more useful than photoshop.

Ragnarok online have quite large sprites, therefore it is unlikely that they places pixel for pixel. Most likely they paint it with some kind of paint tool like photoshop and apply some filters (outline) to give it a certain charm, but at most it is faked pixel art.


#4996477 Deferred shading - problems with normal map

Posted by Ashaman73 on 02 November 2012 - 03:25 AM

I wonder why normal maps can store normals that go in the face they are displayed on

They don't need to. A simple, though extreme, example:
1. Polygon normal points up, directional light source from the left => polygon is perpendicular to light source => no lighting at all
2. Same as 1, but you have a normal map with normals pointing to the left => polygon is still perpendicular, but some normals pointing directly to the light source => texel get directly lighted by light source

As you can see, you don't need any normals pointing into the surface. This is the extreme case, more sane normals will have the same problem, even if they don't get lit with a high intensity.

TBN-matrix you need a vector with values from -1 to 1 but why do I store those vectors in the final normalmap?

Most often you only need this for the x,y component, which is absolutly legal and necessary. The z component (pointing away from the surface) is in 99.9% of the time positive, this is the reason all the normals maps got this bluish tint(z-component=b channel > 0.5). But as stated above, the problem is not that a normal is pointing into the surface.

I guess i have to play with the tangent-space normalmaps then.

This is not a problem you can solve by playing around with the tangent-space normal maps, you can only lessen the effect by reducing the angle between surface normal and tangent normal. If you want to get rid of the effect, use either surface normals for normal map culling or shadow mapping or accept it :)


#4996448 Binary Tree that Grows as the Program Runs

Posted by Ashaman73 on 02 November 2012 - 01:14 AM

Why should we do your homework ? What would happen if you fail ?

1. Nothing, it isn't important to succeed, I do it just for learning. => well, then try harder, you will learn !
2. OMG, I need it to get accepted. => well, if an other student did made it, it is justified that he got the place instead of you, sorry to be honest.

I have spoken with my professor, and he has not helped much.

This is the best hint, that you should solve it yourself. Why do you do it when you don't want to learn it at all ?

Thank you mighty programmers of gamedev.net

Honey didn't help you, nor your dignity.

helpful posts will be rated as such.

hhmmm... I'm still getting a good rating ?


#4995826 is Ragnarok's art Pixel Art ?

Posted by Ashaman73 on 31 October 2012 - 08:05 AM

Hard to say. I would not really call it pixel art, but painted sprites (pixel art often use dithering, reduced color palett etc). It is likely that they use a painting tool like photoshop for painting sprites.


#4995824 OpenGL Not Rendering Models

Posted by Ashaman73 on 31 October 2012 - 08:02 AM

1. Check if you don't call this between a call of glBegin and glEnd.

2. Check for errors before this call and after this call, because the error will refer to the last ocurred error, which could be produced by a previous ogl api call .


#4995816 What am I doing wrong in my algorithm?

Posted by Ashaman73 on 31 October 2012 - 07:36 AM

I've looked at your code and your indicies magic is ...interesting Posted Image
You already ensure, that newly added walls are not connecting your growing room set, so I would guess, that you have a bug in your indicies magic somewhere ? Ie when adding the rooms to the set of already proceed rooms.

I think I got it. The problem is, that you merge three sets instead of two sometimes. When you find two rooms in different sets, you need to merge the sets. But in your case you only check if not both rooms are in the growing set (=knockedDownRooms), but it could be, that none of the two rooms are in this set. In this case you would merge three sets, the two single room sets and the knockedDownRooms set producing a potential island. When using ordered walls, it is always ensured, that one room is in the knockedDownRooms

Solution 1:
Instead of using a single set (knockedDownRooms), start with sets for each single room and merge them accordingly.

Solution 2:
Update your condition from
if (knockedDownRooms.Contains(roomsAndFloorType[0]) &&
									    knockedDownRooms.Contains(roomsAndFloorType[1]))
									    continue;
to
if (knockedDownRooms.Contains(roomsAndFloorType[0]) && knockedDownRooms.Contains(roomsAndFloorType[1]) ||
(!knockedDownRooms.Contains(roomsAndFloorType[0]) && !knockedDownRooms.Contains(roomsAndFloorType[1]))
									    continue;



#4995808 What am I doing wrong in my algorithm?

Posted by Ashaman73 on 31 October 2012 - 06:52 AM

Sorry, I don't checked your code yet,

but looking at the algorithm it seems to be kruskal (minimal spanning tree, nodes=rooms, edge=knocked down edge).The condition you need to hold up is, that each set of rooms have exactly rooms-1 knocked down walls (add a debug output to check it). When you choose a random wall, you need to ensure that this wall connects two rooms in two different sets, else you will introduce a cycle (you have more than one way between two different rooms in a single set).


#4995792 OpenGL Not Rendering Models

Posted by Ashaman73 on 31 October 2012 - 06:03 AM

It is hard to tell a problem from text only. Could you please provide some comparision screenshots ? Have you checked for opengl errors ? There're always differences between ati and nvidia GPUs and it needs some time to fix all issues which runs on only one plattform.


#4995725 Deferred shading - problems with normal map

Posted by Ashaman73 on 31 October 2012 - 01:19 AM

Even if I only display dot(normal,lightdir) I get light artifacts on the faces the light shouldn't reach ...

At the first glance I would say, that your normals are correct. I guess that you have a missconception. When you have a surface facing away from your lightsource, the angle between surface normal and light is greater than 90 degree which lead to cutting off the light. But applying a normal map to this surface, the normals rendered to the gbuffer start to bend and this could lead to bending to less then 90 degree which lead to lighting of back faced surfaces.

Either try to avoid such drastically normal maps to lessen the artifacts, use a shadow map or save the surface normal too. The latter is quite easy, but will cost additional bandwidth, but in this case you would leave out the lighting calculation if the surface normal is pointing away.


#4995315 Feedback on Unique Zombie Survival Game Idea?

Posted by Ashaman73 on 30 October 2012 - 01:07 AM

I'm open to constructive criticism, ideas that I could add to my game, and, ultimately,

Hmmm... you have some hard requirements for your criticism. At least I would sugguest to look into modding an existing game much like DayZ, these will bring you an huge step closer to your goals.

the question: would you play it?

No.


#4995308 Concurrent rendering & game-logic

Posted by Ashaman73 on 30 October 2012 - 12:39 AM

There is really not that much of a performance gain you can expect from multithreading your game.

Sorry, but this is BS.

What is the correct approach to concurrent rendering while running game-logic?

The game logic is always hard to make concurrently with other engine parts due to its manipulative nature. Just think about a missle created ad-hoc in the game logic loop, you really need to be careful to not create all the necessary entities (physics, render model, sound files) on-the-fly and add them to the according sub-systems. In this case you should work with proxies which are in an invalid state until properly integrated at a given sync point.

As L.Spiro said, I think that multithreaded rendering, or atleast creating multiple command queue concurrently can help.

But there's still hope to optimize the rendering without using multithreaded rendering. The basic idea is , to fill up the rendering queue faster than the GPU is capable of processing it. Once the CPU is done, the GPU is still running leaving the CPU for other tasks:

Simplified tasks in a single frame

	  Render   Game logic			Physics  Audio
CPU |--------||------------------||---------||-----------|
GPU   |------------------------------|	 

If you don't want to touch the game logic you can try to extract as much as possible from the rendering task and process it concurrently like this

Simplified tasks in a single frame

CPU 1 |--| Render animation  
CPU 2 |-----|Rendering Pipeline
CPU 3 |---------| Physics
CPU 4 |--Audio---|S|---Game logic---|
GPU   |------------------------------|	
Ie extract the calculation of the animation for the next frame from your rendering pipeline (double buffering), no need to stall the pipeline filling here. S is the Syncpoint, that is, you start with the game logic once all the other tasks are proceed.




PARTNERS