Jump to content
  • Advertisement

Leaderboard

The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation since 07/16/18 in all areas

  1. 3 points
    This has a lot to do with how computers render things. By using this style normal advantages, like mip maps etc, will actually be working against you instead of helping you. You could just try it, modern computers are actually good at dealing with large images. A other more game friendly style would be to either seperate parts using Gimp or other photo editing software. Then to load these in and to reconstruct the scene. You will break them up like this: Then after this you store all the extracted parts on a sprite sheet. Sprite sheets should be power of two 256x256, 1024x1024, 512x128 etc. In Unity you would extract these images, and rebuild the original drawing, using the now more computer friendly sprites. It will be a extra bit more work, yet you will get better performance and still keep your style. The other advantage is that it turns these little pieces into modular assets; that you can re-use to create more content: If you had a whole library like this, made from parts of the other exclusive buildings, you could create a very unique world full of details. I really like your art style. Fantastic colors and shading.
  2. 2 points
    You're asking us to break the law? Nobody here has the right to distribute those graphics, so even if they knew how to break the protection, they could not give you the files. Most likely you are already violating a law by distributing the files (I assume that's waht is inside help.zip at least?) Finally, you're not making sense. You say you can make graphics, but instead of making your own graphics and make a game inspired by this retro game (which you would have full ownership of, so you can distribute it for example, or even sell it), you want the copy-righted graphics that are not yours, so you will never be able to show your remake to anyone else. I fail to understand what your aim is, to be honest. I'd suggest drop the files, make your own graphics, and learn coding. That seems a much more useful direction to take. Using copyrighted data that is not yours can only lead to trouble.
  3. 2 points
    You would need to figure out your tile size then make a variety of versions which are seamless otherwise the edges wont match up when tiled. Some tiles can be just a sidewalk, road, or grass, others will need to have grass edges or road, ect... and keep in mind you need to consider all directions and corners. This is a tile map example:
  4. 1 point
    On GCN, LDS and GDS are totally useable from pixel shaders. It just isn't exposed in DX11 or DX12 SM5 (for obvious reasons) so it isn't going to help you on PC Also, from AMD GCN block diagrams - 1 rasteriser reads 1 triangle per cycle and outputs 16 pixels per cycle. After shading, each Render Back-End (there are usually 2) can do multiple blends, depth and stencil samples per cycle. Looks pretty dedicated to me
  5. 1 point
    Please not tht this is a "a,game AI" forum 99% of the people here wouldn't have any clue about the problem here and of those and of tha t do perhaps 25% might have an inking. Regardless, a game AI forum is not great place to ask games about non-game AI.
  6. 1 point
    The simplest solution is using a shared pointer such as std::shared_ptr, otherwise you may roll your own reference counted pointer. // pseudo code struct MyPointer { MyClass * pointer; size_t count; }; struct MyPool { MyClass * requirePointer(someKey) { MyPointer * myPointer = findBySomeKey(someKey); ++myPointer->count; return myPointer->pointer; } void releasePointer(MyClass * pointer) { MyPointer * myPointer = findByPointer(pointer); --myPointer->count; } }; But I would highly recommend using std::shared_ptr instead of your own reference counting.
  7. 1 point
    Yeah, i already expected this to happen meanwhile. The problem is we have no smooth 'tangents' at the control points, if we would compare the approach to converting a catmull rom spline to bezier spline, which is what i have in mind basically. Should be easy to fix. Lets say we have a catmull rom spline of N quats, and we are at control point i: quat cpQ[N]; for (int i=1, i<N-2, i++) { quat diff_left = rotation from cpQ[i-1] to cpQ[i+1] // 'segment' from previous to next control point (before we used from current to next) // divide angle by 6, because the 'segment' we use to calculate the 'tangent' now is twice as long quat modified_left = rotate cpQ by diff_left int j = i+1; // index for right control point quat diff_right = rotation from cpQ[j+1] to cpQ[j-1] // divide angle by 6 quat modified_right = rotate cpQ[j] by diff_right ... } I'm not really sure this works really continuously, because i miss experience with quad slerp (and i expect some wobbling because the camera view vector likely will not be aligned to the position spline tangent exactly). If it does not work well, you could look at this:
  8. 1 point
    One reason for this is to prevent ambiguities. Numeric literals can have a suffix to indicate their type, e.g 42l. Without a rule saying that identifiers don't start with a number, it may not be clear if such tokens were identifiers or literals.
  9. 1 point
    Hello I am trying to create a grid of images in pyglet and python and I am not sure where exactly I am going wrong. The goal is for it to be a Breakout/Arkanoid clone. The problem I am having is getting the brick images to display in a grid. Here is the code that as far as I can tell, should place the bricks in the correct position. class Brick(): def __init__(self, space): # Create the list to hold different sprite bricks and load images self.batch = pyglet.graphics.Batch() self.brick_images = ['brick1.png', 'brick2.png'] self.brick_sprites = [] # 1 out of 5 chance to drop a power pill self.chance_to_drop = 1 # Set the images anchor point to its center and create sprites for i in range(len(self.brick_images)): img = pyglet.image.load(self.brick_images[i]) img.anchor_x = img.width // 2 img.anchor_y = img.height // 2 self.brick_sprites.append(pyglet.sprite.Sprite(img)) for x in range(7): for y in range(7): self.body = pymunk.Body(body_type=pymunk.Body.KINEMATIC) # The position where each pymunk body will be placed self.body.position = x * 100 + 75, y * 30 + 340 self.brick_type = random.randint(0, len(self.brick_sprites) - 1) if self.brick_type == 0: sprite = self.brick_sprites[0] # Set the sprite to the same position as the pymunk body sprite.set_position(self.body.position.x, self.body.position.y) sprite.batch = self.batch elif self.brick_type == 1: sprite = self.brick_sprites[1] sprite.set_position(self.body.position.x, self.body.position.y) sprite.batch = self.batch self.shape = pymunk.Segment(self.body, (0, 0), (50, 0), 6) self.shape.elasticity = 0.80 self.shape.collision_type = collision_types['brick'] space.add(self.body, self.shape) handler = space.add_collision_handler(collision_types['brick'], collision_types['ball']) handler.separate = self.remove_brick So what I am trying to accomplish is have 7 rows of 7 bricks. As far as I can see the sprites are being created in the loop, but when I run the program only 2 bricks are being displayed. I am sure there is something wrong with the way I am looping but honestly just cannot see where I am going wrong. I have spent some time, trying to see the error but simply cannot see where I am going wrong. I can see that the pyglet brick sprites are NOT being set to the correct x, y of the pymunk body, even though, using the same formula for the player paddle object lines up the sprite perfectly. #Set the sprite to pymunk object position self.image = pyglet.image.load('paddle.png') self.image.anchor_x = self.image.width // 2 self.image.anchor_y = self.image.height // 2 self.sprite = pyglet.sprite.Sprite(self.image, x=self.position.x, y=self.position.y) I am very confused with this one and I just hope I have explained everything clearly enough. Thank you for any help or assistance in any way.
  10. 1 point
    The prefab test revealed something really interesting, Unity prefabs work better than any of the terrain detail tools. This image 6250 meshes more than 400 000 triangles. Running at 72 FPS [spoiler] [/spoiler] As can be clearly seen in the image, I used a very simple transparent material for the last Lod because alpha errors will go unnoticed here; I was also able to set shadows per Lod. The better control of the assets combined with Lods and better batching resulted in much better coverage than expected. The grass isn't marked as static, and applying rotation to each only dropped the frame rate to 66-68FPS. Increasing the amount of grass by 250 reduced the frames to 40FPS, indicating I hit the geom limit of the graphics card. I know I need only 3800 - 4000 meshes to get the cover I need, I can go up to 6250 - 6300. I was expecting a number just above 50% of Unreal this is 60%. On a high-end PC, there is no point to a test like this as both Unreal and Unity allow for more grass than you need, although I would never have known just how badly the terrain tools perform against the normal prefabs.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!