Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Feb 2007
Offline Last Active Today, 07:44 AM

#5217873 Do you pay per click or installs with Facebook and Twitter ads?

Posted by on 20 March 2015 - 09:38 AM

Intelligence Is Like Lego

What is the point of that photo? And why did the post get up-votes? What am I missing?
when you pay for installs or clicks, that photo shows you what you're often buying - the time of a click-factory-worker who will click on links or install applications from a huge array of devices.
Sure, your install base has gone up, just like you paid for. Too bad there's no legitimate users on those devices though...

#5217861 Do you pay per click or installs with Facebook and Twitter ads?

Posted by on 20 March 2015 - 08:46 AM

AFAIK with facebook ads you pay for impressions, which may or may not turn into clicks, which may or may not turn into installs.


There's 3rd party services which sell likes / installs... but this are against the Facebook terms of service.

This actually creates huge issues for legitimate advertisers though!


Facebook will try to ban people who sell 'likes' (as pictured by Code Fox), so in order for these people to avoid detection, they have to 'like' a lot of random things, as well as the things they're being paid specifically to like.

This means that when you pay Facebook for a legitimate advertisement, there's a huge chance that you'll get clicked on by these illegal like-sellers, which is useless to you, as they're just fake accounts run by bots / sweatshops... So even with legitimate facebook ads, you often end up just buying fake 'likes'.


These fake likes are then toxic for your page. Whenever you post something on a page, facebook doesn't automatically send it out to all your followers -- they do it batch by batch to see if it's actually engaging. If you've got a lot of fake followers, they won't engage with your posts, so your post will stop being propagated once it hits a batch of fake accounts...


TL;DR Facebook advertising is very broken.

#5217816 Graphic corruption

Posted by on 19 March 2015 - 11:47 PM

Looks like the kind of race condition bugs you get when reading + writing from/to the same texture at the same time, or when you don't insert a sync point between a draw-call that writes to a texture, and the next draw that reads from that texture...

...but GL should protect you from these kinds of shenanigans, right? Right?

#5217637 Has royalty share ever worked?

Posted by 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 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 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.


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:




#5217554 Has royalty share ever worked?

Posted by 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 on 18 March 2015 - 09:42 PM


Time to get started on your Vulkan ports biggrin.png

#5217525 glSyncFence correct usage

Posted by 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 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 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 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 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 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 on 17 March 2015 - 07:08 PM

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