Tag Info

New answers tagged

0

This apparently has to do with how MipMaps are generated, though, in personal experiments I could not reproduce your problem to quite the magnitude you have. My best guess is that you got a double-threat going on: Unity may not be importing the mesh at a high enough resolution, and the gradient color you have going on there may be calling more attention to ...


3

I don't know much about java.awt but from the documentation I can tell you this: The antialiasing option you are using does not use multiple samples like MSAA and thus does not support the MSAA x2, x4 ... sample counts. The antialiasing method of awt blends the edge pixels with the destination surface by using the exact coverage of the target pixel as the ...


2

Since I am not familiar with shaders at all - I recommend this approach: Create a texture in your favorite editor whether it be GIMP or Photoshop. Leave some sort of radial transparency in the center of the image so the player can actually see what he/she is doing amidst the red bordering the edges of the screen. Add that image to your XNA project, and ...


1

Say, for the sake of example, that you were pondering your GT8500 and whether you need to replace it. Here is the only relevant part of your card's spec: API Support Complete DirectX support, including Microsoft DirectX 10 Shader Model 4.0 Full OpenGLĀ® support, including OpenGL 2.0 If you intend to use features beyond these in your game, ...


0

Evan is right if you have the artist bandwidth, otherwise, you could make this algorithm a lot more efficient. The issue you have is that you're twiddling individual bits in about the most expensive possible way you could. Right now, you're testing each pixel individually to see if it's blue and changing it if it is - however, you said that you're drawing ...


0

You could reserve a certain color value in your image to be the "tint color", something you are unlikely to actually use like (0, 255, 0). Then create a function that copies the image and loops through all the pixels, every time you find the tint color replace it with some other color using setRGB(). Then for each zombie variant, create a new variation of ...


0

Evan seems correct. It may also be possible to divide the zombies into two textures; one consisting of any parts of them not likely to change color (ie, skin) simply floating in midair, and another for parts of them that may change tint (ie, shirt). You could draw these on top of each other, and specify a tint color only for the second texture in the ...


2

You would probably be better off having your artists produce variations on the default color set, and decide which one to use when the zombie is initially created. The implementation you are using now performs per texel checks to only change a specific color, and say your image is 100x100, that is 10,000 color checks per zombie, on top of the final draw ...


0

I'm currently following the tutorial by Lode Vandevenne: http://lodev.org/cgtutor/raycasting.html. Note that this is only part 1 (basic raycasting and textured walls). Part 2 (ceiling and floor textures) and 3 (sprites) can be found by clicking the link "Back to Index". I think it's great. It contains everything I needed to make my own engine. The tutorial ...


2

How do I use the engine's vertex shader while still allowing the programmer to provide his/her own vertex shader for other calculations in their game? What is the normal approach here? There is no normal approach because engines generally don't let you do that. Generally speaking, engines take one of two approaches: either the user provides none of a ...


2

Higher-end engines typically use a higher-level abstraction than an individual shader. Simpler games just allow each model/material to specify shaders and then to use HLSL includes or the like to allow all common code to be easily reused. You'll need a bit of discipline in applying the shader includes properly and it can be a bit repetitive sometimes, but ...


0

Thanks to the contributors who answered this. I went with my own solution in the end because it was simply enough to implement and gave perfect results. All I had to do to scale the acceleration, was the following: float fallAccel=(dt * num); //Where num is any arbitary amount and dt is the delta time between frames (hence it is scaled and also ...


3

Part of the problem is that your notion of 'velocity' isn't physical. Your updating of position is fine: spriteYReal = spriteYReal + (spriteYVel * dt); sprite.yScreen=(int) (spriteYReal*r.height); This just says that the sprite's position is computed as Pnew = Pold+V*dt, which is fine - it means that V=dP/dt, which is correct. The problem is that the ...


0

Physics update rate must be independent from rendering frame rate. Becase it's not exactly 60 fps. void update( float dt ) { float maxStep = 1/60.0f; if (dt > 0.25) dt = 0.25f; // note: max frame time to avoid spiral of death accumulator_ += dt; while (accumulator_ >= maxStep) { physical_world_->Step(maxStep); ...


4

This effect is called Tunnel effect and has been popular in Demoscene. Basically it's a texture mapped infinite cylinder. The camera is moving inside the cylinder or the camera stays still and the cylinder is moving. Here is a video of this effect without alpha blending to make it more obvious and the source code for it. Basic idea was to raytrace the ...


1

I don't know much about Untiy but I know how effects like that are produced. They take randomly generate particles around the area, I'd guess they used Perlin Noise. And in each update, if the particle is no longer visible, it's deleted to make more room for new particles. This should produce the effect you are looking for. Here is a few links on Perlin ...


0

As RobCurr has mentioned, it's probably best to only load the necessary resources during the splash screen. Then load the absolute critical when you go to run the game. There are a couple different approaches to persisting your graphical resources across different activities. Basically your problem is "How to maintain global variables/state across ...


1

jogl 2.0 have added profiles, this is important in order to support the new shader only based OpenGL contexts. The base GL class only contain functionality that is still common across all OpenGL profiles. http://jogamp.org/jogl/doc/Overview-OpenGL-Evolution-And-JOGL.html To fix your code you first need to request a fixed function compatible profile. This is ...


0

Making a big square that covers the entire game world is a fine approach unless you run into some problem with it. There are a couple of potential problems you should remain aware of that could make it better to tessellate the water a bit more: If the game world is very large, the water vertices will be very far away from the camera. It's possible to run ...


0

You'll be fine with the first approach. Just don't make them too far away or you'll run the risk of having some odd graphical glitches due to floating point imprecision happening.


2

That's really not that important. Computers nowadays are fast, more important is not to use a "dumb" approach. When I first started programming in OpenGL (for Android, OpenGL 1.0) I made a Minecraft-like game, but instead of using VBOs or moving to OpenGL ES 2.0 I sent all vertex data, every frame to the GPU. You can imagine how slow it was. I was getting ...


1

As long as you do not require the vertices for animation and you don't want to have caves or other holes below sea level you should probably use your first approach: If you render the water after your land geometry all fragments not visible will get depth culled which is very efficient. The water geometry is clipped before shading the fragments which means ...


0

I think this is a realy broad question. There are several factors to each shader that make them diffrent. And im not sure how the Target api looks, but for what ever engine you are using and coding with, this is always a hussle. So my best guess is that it could be anything from 10 houers to a milion. this comes down to how fast you understand the idea ...


0

I would explore precalculating textures that cover a number of your grid cells. Combined with rendering more distant grid cells from the precalculated textures, at a distance that only requires, say, 64x64 mipmaps (instead of your original 256x256 textures) then you could draw up to a 32x32 array of grid cells in one batch with a precalculated 2048x2048 ...



Top 50 recent answers are included