Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Nov 2006
Online Last Active Today, 10:23 PM

#5283999 Object Space Lightning

Posted by on 29 March 2016 - 12:14 AM


E.g. lighting semi-transparent objects

I don't get this one. How would you do that?


The difference between OSL and a standard deferred renderer is, that you have a 'g-buffer' per object, so you can calculate the lighting of the surface independently of what is behind or in-front of the object in the scene. So, calculate the lighting in os/ts and forward render the object into the scene using standard alpha blending.

#5282873 create big instance buffer

Posted by on 23 March 2016 - 08:02 AM

Theoretically GPUs are able to process lot of vertices, but you will have some limiting factors. For one memory bandwidth. If the vertex shader is so optimized, that it will be optimized to output such an insane number of vertices per frame, then you will get bandwidth issues. The second fun will be, when I understood you right, that you want to render grass (obviously single blades of grass ;-) ), most likely alpha blended ? This will result in lot of overdraw (no early z-rejection) and you need to sort it when changing the camera angle. Caching your data in 100 buffers sounds like a better approach.

#5282821 create big instance buffer

Posted by on 23 March 2016 - 02:36 AM

Well, the problem should start with memory. You save a 4x4 float matrix per instance , right. So 64 bytes per matrix, you would need ~6.4 GByte for 100 000 000. It would be roughly ~1.1 GByte for 18 000 000, just for holding the data structure. Should it exists in v-ram ? Do you need some more data like texture, screenbuffers etc ?

Even if memory would be no issue, you would need to render 18 000 000 instances, how many faces will one instance have ? A simple cube would result in 12 tris, finally resulting in 216 000 000 tris per frame.

Even if performance would be no issue, you have 216 000 000 tris on a 1080p display with 2 138 400 pixels, which are rouhgly 100 faces per pixel, if you only want to render a simple cube. So, this would be either overkill or the really, really lazy way to render a large world.

I think this has enough potential to introduce some issues :D

What is your goal ?

#5282806 Odds of success as an indie publisher rather than a dev?

Posted by on 23 March 2016 - 12:11 AM

You want to be a publisher, like EA just in small ?

Well, real publisher will carry almost all of the financial risk and will be responsible for the #1 selling point: marketing.

Most games will not break even and there are some super-hits which will hopefully cover the loss of all the other titles. There is a reason why some big publishers died in the last years, even with good titles (eg THQ).

So, the real question is: Why do small teams reallyself-publish ?
Answer A: Hey, they wanna make more money...
Answer B: Eemm.., well, no publisher is interested to bear the risk...

Making money with a title is 99% marketing and a good publisher will be we excellent here. So, if you want to be a publisher and you want to make money, you would need to be excellent in marketing, networking, raising capital...

#5282537 Understanding the difference in how I should be drawing lots of objects

Posted by on 21 March 2016 - 11:52 PM

My previous implementation was based on pure immediate mode too (begin/end). I converted my gui rendering by doing this:
1. Choose a common format for all widgets (e.g. 4 vertices each having 1 tex coord,color etc.), one which can be mapped directly to the VBO.
2. Exchange the begin/end by writing the data to a cache, so instead of glVertex(xx) use something like data.position=xx
3. Caching was really useful for static text which have several hundred quads and changed really seldomly.
4. Map the "back" VBO (aka accessing the VBO memory directly)
5. Copy the displayed widgets from the cache to the "back" VBO each(!) frame (a simple memcpy if both use the same memory setup)
6. Unmap the "back" VBO (aka asynchroniously upload to the GPU memory).
7. Render the "front" VBO which has been updated and upload one frame before, so that the GPU renders one VBO while the other is uploaded (important to avoid stalling!).
8. Swap back/front VBO for the next frame.

This way I dropped my API calls according to gDebugger by 15k calls. Although, immediatemode is depreacted in OGL 3.0 and above.

#5281834 a* early exit on impossible set?

Posted by on 18 March 2016 - 05:42 AM

For my game aborting after X tries is enough, but if you want to use a bulletproof system, you should look into build waypoint islands. That is, every waypoint or tile get an island id. You start with processing the whole map once and whenever the topology changed (eg. connecting two islands), then before starting A* check if both waypoints (start and end) are on the same island. If you have lot of dynamic connections between islands (small houses with doors etc.), you could build an island graph (island A is reachable from island B etc.) and apply A* first on this island graph before going in detail.

#5281822 a* early exit on impossible set?

Posted by on 18 March 2016 - 03:07 AM

Just two tips. First limit the nodes you visit,abort if you do not find a solution with the given number of nodes. Second, start your search from the goal node (reverse search), with the assumption, that a goal is more often blocked then the entity, the algorithm will stop more often and earlier.

#5281816 Understanding the difference in how I should be drawing lots of objects

Posted by on 18 March 2016 - 01:45 AM

This is how I do it in my engine (first the basic idea):
1. One VBOs for all gui elements (text,buttons etc.)
2. Map the VBO, then write all widgets in the correct order to the VBO.
2.1 Remember the shader which will be used to render the widgets in a non-GPU memory (an ubershader + branching would work too).
3. Unmap the VBO
4. Bind the VBO.
5. for each widget activate shader & draw the widget (ranged draws).

To optimize it:
I. Use two VBOs, double buffering them which will display the GUI with one frame delay.
II. Merge the draw calls, if follow-up widgets use the same shader.

The latter works especially good for text rendering.

#5281815 Comments about HLSL array packing policy

Posted by on 18 March 2016 - 01:13 AM

Have you tried to move the intensity right after the pos, so that all your 3-component vectors are aligned again ? pos.x,pos.y,pos.z, intensity,col.r,col.g,col.b,is_on

#5281308 A moddable MMOG

Posted by on 15 March 2016 - 01:46 AM

A core game mechanism is more or less a single game mechanism, not a list. E.g. in a FPS shooter the core game mechanism is "shooting at stuff", regardless if you have a ladder-system, multiplayer,crafting,roleplaying system attached to it. If "shooting at stuff" is not fun, too clumpsy or whatever, your game will never work, regardless of how many other features you add.

> rely heavily on typical hack-and-slash mechanics

So, is this your core game mechanism ?

Zelda is a finished game and not a game mechanism. The importance of a core game mechanism is, that all other game mechanism you will add, will either support your CGM (good), will not support it at all (sometimes good/sometimes bad), will compete with it (bad!). E.g. if you have two really powerful CGM, you would actually develop two different games, so the supporting GM needs to respect its supporting role, else you would tear your game design (aka chasing your customers off).

Think about your CGM as what the player will experience first and for the rest of the game. Everything else can be introduced later.

So, if hack-and-slash mechanism is your core game mechanism, like in Diablo ? Start with it. Prototype it, test it out until it is fun.

#5281303 A moddable MMOG

Posted by on 15 March 2016 - 01:02 AM

A game is seldomly a technically problem , more often a design, time or cash problem (art/server farms etc.).

To get your design right, you should define your core game mechanism and ignore all the rest for now. Really, get your core game mechanism right and build the rest around it. If you start with all the features you want to add without knowing how your core game mechanism actually plays, you will throw a lot of stuff away and you will do a lot of refactoring.

So, what is your core game mechanism ?

#5280678 Selling a game on Steam- Steam and VAT cuts...?

Posted by on 11 March 2016 - 05:53 AM

> A digital publisher can buy the rights to a good for 90c per unit, sell it for $1 per unit, make a profit of 10c per unit, but then be required to pay 17c to a European tax office. WTF is up with that?

This is how it would work in germany more or less: As company you would pay € 0.90 which would include € ~0.17 VAT. Then, when you sell it for € 1 you would pay €0,19 VAT, but you can set this off, so that you only need to pay € 0,02 VAT actually, so only the end-consumer will need to "pay" the VAT, not the company.

#5280677 Cheating with graphics

Posted by on 11 March 2016 - 05:44 AM

Out of my head:

Indie shooter with high-level of abstraction: Superhot
High level of detail abstraction and color choice: The Witness
Extreme high abstraction: Geometry Wars
Detail abstraction: TF2
Shape abstraction: Minecraft

There are much more, but I would need to look them up.

1. Abstraction will help you to define limits (good for indie/hobby devs)
2. Limits will help you to define an unique style.
3. A unique style will help you to distinguish your title from others.
4. A distinguishable title will help you to attract people.

The worst think you could do as hobby/indie dev is to target realistic/mainstream art.

#5280651 A ray with an ending position?

Posted by on 11 March 2016 - 01:38 AM

Technically it is more or less the same, two vectors.

Semantically a line is has a start and end which can be represented as (position, position+direction) or (start_position,end_position). Well, a ray is typically a start point with a direction vector, so (position, direction), where direction is typically normalized.

Therefor it is easy to get a ray from a line by just normalizing the direction, either (position,normalize(direction)) or if you have a start-,endpoint you get (start_point, normalize(end_point-start_point)).

But, once you have a ray with an normalized direction, you can't extract the original line back.

#5280646 Selling a game on Steam- Steam and VAT cuts...?

Posted by on 11 March 2016 - 01:16 AM

The GST is most likely already included in the final price, much like over here in germany (thought we have a VAT of 19% :( ), I think that there's a tax agreement between USA and Australia. So, the developer will only see 90% of your $20 minus -30%. In each country, each market, customers will be used to different final prices. In some countries the final price will always include the VAT, in other countries people are used to add them on top.