Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Hodgman

Member Since 14 Feb 2007
Online Last Active Today, 09:18 PM

#5217637 Has royalty share ever worked?

Posted by Hodgman on 19 March 2015 - 08:19 AM

Wow, that's quite an amazing game for an Indie studio

There's a big difference between "indies" (independent games studios), and "indies" (groups of random people on the internet) biggrin.png

 

If there's an IGDA meetup in your area, go and see if you can meet these kinds of actual developers.

I'm lucky enough to share an office with something like 20 other indie companies, plus there's a hugely active IGDA group in my city (hundreds of people)... so in my immediate network I've met indies working on an MMO exploration game, a whole catalogue of choose your own adventure books, an arcade weapons racer, a car/tycoon simulator, a speed-run 3D platformer, a space trading MMO, amazingly successful mobile games, successful lone wolves, Syndicate-esque top-down tactics, a "minecraft-clone" shooter, co-developers of a dinosaur FPS, a quake-style arena FPS, and surely more I've forgotten to remember laugh.png

Many of them are fairly recent start-ups with fairly small teams, which means there's a high likelyhood that the core team members on many of these kinds of projects are receiving shares in the company rather than actual money to begin with.




#5217558 Could not make a release build of a windows store game.

Posted by Hodgman on 18 March 2015 - 11:45 PM

SV_Target is a shader model 4 keyword.

The error message says that you're using shader model 2. If that's correct, you should be using the COLOR0 keyword instead.




#5217557 How much should be done on the server?

Posted by Hodgman on 18 March 2015 - 11:34 PM

Generally you do the work on both, but the client's version of the work is only a predicted gamestate, which is used to make it look like there's zero latency.

 

 

e.g. the client clicks to shoot a bullet. They send a message to the server, requesting to shoot this bullet. In the meantime, while waiting for the server's response, they continue to run their own simulation, showing the bullet firing, sparks coming off a wall, etc...

Eventually the server responds by telling the client that yes, they did shoot a bullet at X point in time.

OR

The server responds with a game-state in which the bullet was never fired (maybe another player stunned the client first), so the client needs to rewind their predicted gamestate and adjust it to show the server's version of events.

 

Some required reading:

https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking




#5217554 Has royalty share ever worked?

Posted by Hodgman on 18 March 2015 - 10:44 PM

The groups that appear on forums with no experience at all, overly vague yet massive ideas, usually no talent, no idea of the legal/business side of things... that's a complete mess that I'd advise people to steer clear of.


As for successes, there's a studio in the same building as me, League of Geeks, who have built their game using a well defined profit-sharing system. The core of their team are actual development veterans coming from other studios, they've sat down ahead of time and worked out all the legals of doing a profit sharing system, and then they've planned out all the work involved and assigned 'points' to different tasks. IIRC, when they're finished, they'll add up all the points, and then everyone gets a slice of the profits depending on how many points they've earned.

They're only in early access now, but they're looking on track to actually finish their game. At that point, I think they're planning to release their "point system" for other devs to copy if they like.




#5217548 Mantle programming guide and white paper released

Posted by Hodgman on 18 March 2015 - 09:42 PM

http://www.amd.com/Documents/Mantle-Programming-Guide-and-API-Reference.pdf

Time to get started on your Vulkan ports biggrin.png


#5217525 glSyncFence correct usage

Posted by Hodgman on 18 March 2015 - 08:13 PM


Isn't that what I want to do? Wait until the GPU is done with the previous commands, such as glDrawElements and etc
Yeah, but you also want to avoid synchronizing the two processors / causing them to wait on each other. Usually you avoid that kind of synchronisation by allocating more memory (double buffering). Either use two (or more) buffers and switch which one you're using per frame, or allocate the buffer to be twice (or more) as large as usual and switch which range of the buffer you're using every frame.

 

You can either do it fine-grained with one fence per map, or coarse with one fence per frame. I find the per-frame method to be much simpler and faster.

 

Each frame, keep track of which range of the buffer you've written data into. On the next frame, you can't overwrite any of the previous frame's ranges -- you have to write into new ranges.

 

If you're unable to allocate a new unused range (e.g. the buffer is too small), then (go and fix your code to allocate a bigger buffer so this doesn't happen, or) you have to orphan the buffer and get yourself a new one as a last resort. Let's say that we've always allocated a big enough buffer though, so we can ignore the orphaning case.

 

At the end of each frame, insert a fence.

Once the GPU has reached that fence, the range of the buffer used by that frame is now free to use again. At the start of every frame, wait on the fence from two frames earlier.

e.g. At the start of Frame #3, you'll wait on the fence that was issued at the end of Frame #1.

 

Buffer: [[Buffer Range A][Buffer Range B]]

 

Frame 1 commands: 

Draw using range A.
Draw using range A.
Draw using range A.
Fence #1.
 

Frame 2 commands: 

Draw using range B.
Draw using range B.
Draw using range B.
Fence #2.

 

Frame 3 commands: 

Client wait on Fence #1

Draw using range A.
Draw using range A.
Draw using range A.
Fence #3.
 
This avoids a CPU/GPU sync, as the GPU has a healthy buffer of 1-frame's worth of commands in between when a fence is issued, and when it is waited on.



#5217520 Couple of questions regarding graphics API?

Posted by Hodgman on 18 March 2015 - 07:53 PM

Also, step 1 for developing for consoles is to become a licensed developer, sign the contracts, and get your hands on the SDKs and hardware.

 

If you can't imagine yourself doing that in the near future, then it's just a pipe dream... and you should probably focus on a realistic goal.




#5217513 how to comunicate with diffrent exe files?

Posted by Hodgman on 18 March 2015 - 07:20 PM

As mentioned above - IPC, or "inter-process communication", is a good search term for ways to communicate between different exes.

 

Last time I needed this in C#, I used Win32 named pipes.




#5217491 How 3D engines were made in the 80's and 90's without using any graph...

Posted by Hodgman on 18 March 2015 - 06:22 PM

Back in the day, you could get a pointer to the array of pixels that the monitor was reading from, and just write your own pixel data into that memory.
You can do the same thing today, but using a minimal amount of D3D/GL/SDL/etc code to manage that array of pixels for you.

Then you just have to implement your own software rasterizer so that you can draw pixels :D


#5217248 Drawing only part of VBO?

Posted by Hodgman on 17 March 2015 - 08:06 PM

You might be after glDrawRangeElementsBaseVertex -- the basevertex param lets you specify an offset (in number of vertices) into the VBO where it will read from.




#5217246 Can we use openCL on consoles?

Posted by Hodgman on 17 March 2015 - 07:54 PM

Sony calls their shading language PSSL. Different consoles do use different languages... however, they're all so extremely similar to each other that you can very easily write code that compiles correctly on every platform (using a few #defines to rename keywords, etc)... so they're all pretty much HLSL.




#5217233 Can we use openCL on consoles?

Posted by Hodgman on 17 March 2015 - 07:08 PM

For any console GPU or GPGPU tasks, you'll use HLSL.


#5217209 What are your opinions on DX12/Vulkan/Mantle?

Posted by Hodgman on 17 March 2015 - 05:30 PM

Well in a CPU bound situation, the GPU will starve every frame until you can manage to get your CPU frametimes below your GPU frametimes.

As for the copy, say we're lucky enough to have a 20Gbps bus -that's ~2.33 GiBps, or ~2.38 MiB per millisecond, or ~2.44 KiB per microsecond!
So, 64KiB could be transferred in ~26 microseconds.

On the other hand, if you have to to a GL/D3D map/unmap operation, that's probably 300 microseconds of driver overhead!


#5217190 What are your opinions on DX12/Vulkan/Mantle?

Posted by Hodgman on 17 March 2015 - 04:51 PM

I was thinking in the sense that you batched 4,096 draw calls, before the call even got submitted to the GPU, you'd have to perform a copy to GPU memory for your 64KiB of data. Until that copy is complete, the GPU may not be doing anything at all. However, I am quite possibly vastly underestimating the speed of such a copy (which is probably on the order of microseconds).

If you do it properly, copying data is completely asynchronous, in that it only involves CPU work - the GPU is unaware.
Also, the GPU is almost always 1 or more frames behind the CPU - i.e. The OS/driver are buffering all your draw calls for 1+ frames.
Stopping issuing draws to copy some data, or run gameplay code, etc will not starve the GPU, because there's this massive frame long buffer of work. As long as once per frame you submit a frame's worth of work, the GPU will never starve.


#5217042 Stuttering problem - first attempt at fixed timestep game loop

Posted by Hodgman on 17 March 2015 - 04:35 AM

The only way to completely solve stuttering it to vsync to the refresh rate and make sure you never miss a frame.

All timing in all games is broken.
We measure the elapsed time of the previous frame, and use that to decide how much simulation to do in the next frame.

What we really want, is to predict how long the next frame will take to process ahead of time, and then simulate that amount of time.
This is an impossible feat... Unless every frame takes the same amount of time!




PARTNERS