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!


mark ds

Member Since 07 Jan 2010
Offline Last Active Mar 29 2015 06:17 PM

#5214860 Very strange FPS fluctuation

Posted by mark ds on 05 March 2015 - 06:35 PM

You have a simple math problem

 

What if UpdateGame() & RenderGame() take 7000ms? At the end of the frame you're subtracting 1000ms, when in fact you should be subtracting 7000ms.

 

Read up on:

 

Dewitters game loop

know you time-step

Fixed-Time-Step Implementation

 

In that order




#5213667 Optimizing games for mobile platforms(Windows Phone).

Posted by mark ds on 01 March 2015 - 09:40 AM

If you'd read as far as the second paragraph you'd notice:

 

 

This section contains more information on using Direct3D in a phone app, including API and shader support, differences from the desktop platform, and performance optimization.




#5213665 Optimizing games for mobile platforms(Windows Phone).

Posted by mark ds on 01 March 2015 - 09:33 AM

Start here




#5212332 Eliminating texture seams at terrain chunk

Posted by mark ds on 22 February 2015 - 03:45 PM

Are you sure your texture is tileable? It certainly doesn't look it. Try downloading a proper tiling texture, and see if the problem still exists..




#5211887 How to limit your FPS ?

Posted by mark ds on 20 February 2015 - 08:04 AM

 

 

jumping between full and half fps when your game runs close to the threshold is irritating.

 

 

 

The opengl swap_control_tear extension is exactly what you're after. It allows an instant swap if you miss v-sync, otherwise it acts as if v-sync was on.

 

Just to add: all you need to do is add wglSwapIntervalExt(-1)




#5211789 OpenCL for both AMD and NVidia graphics cards with MinGW?

Posted by mark ds on 19 February 2015 - 06:28 PM

I know it's not quite the same, but can't you use the GL_ARB_compute_shader? Assuming you have access to version 4.3.

 

 

    Recent graphics hardware has become extremely powerful and a strong desire
    to harness this power for work (both graphics and non-graphics) that does
    not fit the traditional graphics pipeline well has emerged. To address
    this, this extension adds a new single-stage program type known as a
    compute program. This program may contain one or more compute shaders
    which may be launched in a manner that is essentially stateless. This allows
    arbitrary workloads to be sent to the graphics hardware with minimal
    disturbance to the GL state machine.

    In most respects, a compute program is identical to a traditional OpenGL
    program object, with similar status, uniforms, and other such properties.
    It has access to many of the same resources as fragment and other shader
    types, such as textures, image variables, atomic counters, and so on.
    However, it has no predefined inputs nor any fixed-function outputs. It
    cannot be part of a pipeline and its visible side effects are through its
    actions on images and atomic counters.

    OpenCL is another solution for using graphics processors as generalized
    compute devices. This extension addresses a different need. For example,
    OpenCL is designed to be usable on a wide range of devices ranging from
    CPUs, GPUs, and DSPs through to FPGAs. While one could implement GL on these
    types of devices, the target here is clearly GPUs. Another difference is
    that OpenCL is more full featured and includes features such as multiple
    devices, asynchronous queues and strict IEEE semantics for floating point
    operations. This extension follows the semantics of OpenGL - implicitly
    synchronous, in-order operation with single-device, single queue
    logical architecture and somewhat more relaxed numerical precision
    requirements. Although not as feature rich, this extension offers several
    advantages for applications that can tolerate the omission of these
    features. Compute shaders are written in GLSL, for example and so code may
    be shared between compute and other shader types. Objects are created and
    owned by the same context as the rest of the GL, and therefore no
    interoperability API is required and objects may be freely used by both
    compute and graphics simultaneously without acquire-release semantics or
    object type translation.
 

 

https://www.opengl.org/registry/specs/ARB/compute_shader.txt




#5211756 terrain editor resolution based on height

Posted by mark ds on 19 February 2015 - 03:11 PM

An alternative would be to turn your thinking upside down. Start of with a very high resolution mesh in your editor, and use some method to reduce the number of triangles (Delaunay triangulation, for example) in patches where they aren't needed (and at different LODs). That way you can still use the high res normal (baked into a texture) to give fake detail on distant terrains.




#5211559 Intel card crashes after alt+tab

Posted by mark ds on 18 February 2015 - 04:28 PM

Oogst - do you carry on rendering when your game loses focus? If so, try to stop calling swapbuffers (and pause the game) when you lose focus. I had a similar problem a long time ago, and that fixed it for me.




#5206391 c++ how to detect Enter button input

Posted by mark ds on 24 January 2015 - 09:50 AM

Which operating system are you using, and which programming language?




#5204019 Code appearance, is it really important?

Posted by mark ds on 13 January 2015 - 02:27 PM

It's not just the appearance of the code that matters: the second example shows a clarity of thought when tackling the problem domain, the first feels more like a mental hit and miss approach (i.e. you started coding before you knew what you wanted to code).

 

It happens to everyone - sometimes you just can't see a clean solution to a problem. I often find just walking away from the computer for a few moments can help, or in more complex cases getting out a pen and paper and writing down what you want to achieve, be it in English or via a flow chart or similar.




#5199040 Easiest coding language?

Posted by mark ds on 18 December 2014 - 07:31 PM

To Serapth

 

From Lua's Wiki: Lua is crap!

 

"Lua is a tiny and simple language, partly because it does not try to do what C is already good for, such as sheer performance, low-level operations, or interface with third-party software. Lua relies on C for those tasks. What Lua does offer is what C is not good for: a good distance from the hardware, dynamic structures, no redundancies, ease of testing and debugging. For that, Lua has a safe environment, automatic memory management, and great facility to handle strings and other kinds of data with dynamic size."

 

In  this modern age, battery life is just as important as absolute performance.




#5198350 Easiest coding language?

Posted by mark ds on 15 December 2014 - 10:42 AM

If you're starting from scratch, I'd have to seriously recommend downloading Visual Studio 2013 Community Edition, and learning C#. There are loads of online resources, but better still buy a good C# book.

 

After several months of hard graft getting your head around programming, look into using an existing game engine, such as Unity or Unreal (both of which can be used with C#).




#5197757 Scaling sprites with distance?

Posted by mark ds on 12 December 2014 - 06:48 AM

If you double the distance you halve the size.




#5196878 C++: Easiest way to implement an in-game Time/Date system?...

Posted by mark ds on 07 December 2014 - 06:40 PM

Don't use GetTickCount, use QueryPerformanceCounter along with QueryPerformanceFrequency.




#5195426 laptop for programming

Posted by mark ds on 29 November 2014 - 08:14 PM

How are you finding your Surface Pro? I'm very seriously thinking of getting one. (or maybe the Pro 4)






PARTNERS