I am a student building a senior project in Gamemaker Studio for our capstone project as part of my Game Development concentration.
I am in charge of sprite creation, and currently, it is randomly deleting bits as I draw. So I will draw a couple of bits, and then it will randomly remove the surrounding bits of color. I am becoming increasingly irritated at this and I have no idea why this is happening. Any help would be greatly appreciated.
Effectively, I am designing a character and I'm trying to give his arms a bit more depth so I give him a few more tan-colored muscles. As I do, it erases the rest of his arm.
If you mean the Sprite Editor, then I recommend you using a different program for the sprites, as that one is completely garbage. I'm using Paint.net, its free and works in a similar way like the gms2 sprite editor but better. more plugins, more effects, better shortcut handlings.
If you still wanna stick to the gms2 sprite editor then I'll recommend restarting the game first. that's a problem I never had. Maybe you should check if you are drawing in different layers, and the blend modes of the layers. also maybe your brush is not just a pixel, but maybe a bigger brush.
Related
I want to begin working on a big sandbox game with lots of oceans and islands. This will obviously require a very big map.
I've spent the last couple days researching the best methods on doing this and so far have figured out that
I need to split the terrain into tiles/chunks.
I need to have the player only load those tiles/chunks that are closest to them and unload those further away.
That being said. I would rather avoid flooding my game with a bunch of assets and want to kind of handle things on my own and hard code these systems in myself.
Some questions,
Can I just create a massive 20k x 20k terrain using Unity's built in terrain editing system and then worry about splicing and loading/unloading the tiles later?
or do I need to build my big terrain in an alternative program and import my terrain in then handle the splicing and loading situation?
Also, when it comes to multiplayer. I assume I would just need to basically do the same thing just for each client?
I would appreciate any other tips or guidance on doing this as well. Thanks.
Splitting into multiple chunks but ones that arent too small seems to be the better option, maybe like 4 quarters, that way you are not flooding with assets, you would disable all quarters except the one the player is in.
The problem with making a big terrain is, while you could get a tool from the asset store to split ur terrain later, you will get into the headache of resolutions and sizes and overall I guess its better to split it into 4 pieces or a bit.
You would have a trigger point where you want the game to load the terrain, and depending on which trigger point the player entered you would load the corresponding terrain piece.
For multiplayer, you would do the same thing for each client, making your big terrain as 4 smaller terrains and then loading the corresponding quarter. Tell me if I missed something.
I'm working on a project where I'm capturing people making free throw shots via a video camera. I need a way to detect, as fast as possible, the instant the ball is released from a player's hand. I tried researching a lot of detection/tracking algorithms, but everything I've found seemed more suited to tracking the ball itself. While I may eventually want to do that, right now all I need to know is the release timing.
I'm also open to other solutions that don't use the camera (I have a decent budget), but of course I'd like to use the camera if possible/fast enough. I'm also able to mess with the camera positioning/setup, and what I even want in the FOV.
Does anyone have any ideas? I'm pretty stuck right now, and haven't been able to find anything online that can help.
A solution is to use visual markers (motion trackers) on the throwing hands and on the ball. The precision is based on the FPS of the camera.
The assumption is that you know the ball dimension and the hand grip on the ball that may vary. By using visual markers/trackers you can know the position of the ball relative to the hand. When the distance between the initial grip of the ball and the hand is bigger than the distance between the center of the ball and it's extremity then is when you have your release. Schema of the method
A better solution is to use a graded meter bar (alternate between black and white bars like the ones used on the mythbusters show to track the speed of objects). At the moment there is a color gap between the hand and the ball you have your release. The downside of this approach is that you have to capture the image at a side angle or top-down angle and use panels to hold the grading.
Your problem is similar to the billiard ball collision detection. I hope you find this paper helpful.
Edit:
There is a powerful tool, that is not that expensive named Microsoft Kinect used for motion capture. The downside of this tool is that it's camera works with 30 fps and you cannot use it accurately on a very sunny scene. However I have found a scientific paper about using kinect to record athletes, including free-throws in basketball. Paper here
It's my first answer on so. Any feedback on how to improve my future answers is appreciated.
As an exercise, I decided to write a SimCity (original) clone in Swift for OSX. I started the project using SpriteKit, originally having each tile as an instance of SKSpriteNode and swapping the texture of each node when that tile changed. This caused terrible performance, so I switched the drawing over to regular Cocoa windows, implementing drawRect to draw NSImages at the correct tile position. This solution worked well until I needed to implement animated tiles which refresh very quickly.
From here, I went back to the first approach, this time using a texture atlas to reduce the amount of draws needed, however, swapping textures of nodes that need to be animated was still very slow and had a huge detrimental effect on frame rate.
I'm attempting to display a 44x44 tile map where each tile is 16x16 pixels. I know here must be an efficient (or perhaps more correct way) to do this. This leads to my question:
Is there an efficient way to support 1500+ nodes in SpriteKit and which are animated through changing their textures? More importantly, am I taking the wrong approach by using SpriteKit and SKSpriteNode for each tile in the map (even if I only redraw the dirty ones)? Would another approach (perhaps, OpenGL?) be better?
Any help would be greatly appreciated. I'd be happy to provide code samples, but I'm not sure how relevant/helpful they would be for this question.
Edit
Here are some links to relevant drawing code and images to demonstrate the issue:
Screenshot:
When the player clicks on the small map, the center position of the large map changes. An event is fired from the small map the central engine powering the game which is then forwarded to listeners. The code that gets executed on the large map the change all of the textures can be found here:
https://github.com/chrisbenincasa/Swiftopolis/blob/drawing-performance/Swiftopolis/GameScene.swift#L489
That code uses tileImages which is a wrapper around a Texture Atlas that is generated at runtime.
https://github.com/chrisbenincasa/Swiftopolis/blob/drawing-performance/Swiftopolis/TileImages.swift
Please excuse the messiness of the code -- I made an alternate branch for this investigation and haven't cleaned up a lot of residual code that has been hanging around from pervious iterations.
I don't know if this will "answer" your question, but may help.
SpriteKit will likely be able to handle what you need but you need to look at different optimizations for SpriteKit and more so your game logic.
SpriteKit. Creating a .atlas is by far one of the best things you can do and will help keep your draw calls down. Also as I learned the hard way keep a pointer to your SKTextures as long as you need them and only generate the ones you needs. For instance don't create textureWithImageNamed#"myImage" every time you need a texture for myImage instead keep reusing a texture and store it in a dictionary. Also skView.ignoresSiblingOrder = YES; helps a bunch but you have to manage your own zPosition on all the sprites.
Game logic. Updating every tile every loop is going to be very expensive. You will want to look at a better way to do that. keeping smaller arrays or maybe doing logic (model) updates on a background thread.
I currently have a project you can look into if you want called Old Frank. I have a map that is 75 x 75 with 32px by 32px tiles that may be stacked 2 tall. I have both Mac and iOS target so you could in theory blow up the scene size and see how the performance holds up. Not saying there isn't optimization work to be done (it is a work in progress), but I feel it might help get you pointed in the right direction at least.
Hope that helps.
I'm looking for advice more than direct help.
I am working on an 8 bit platformer game in XNA. I've probably sunk 160 hours into it already, and I'm starting to get into issues with the engine I have. It is basically an adapted/modified version of the XNA platformer demo. All or most of my tiles are 32x32, but some are 64 wide and 32 px tall, like a desk. Some are 32 wide and 64 tall, like a plant.
I am shipping them to the gpu just one .png at a time similar to the way that the XNA tutorial's author does tile mapping. For animated sprites I do use a tile map of different frames of the character. For the tile map data, I read in a text file just like the XNA tutorial.
How should I accommodate for the wide and tall tiles? Should I make a two layered tile system (I figured I should abide by the keep-it-simple-stupid rule)?
Right now I'm using transparent tiles to extend the wide tiles.
Desk with chair:
chair http://dl.dropbox.com/u/8446900/game_screen_desk.png
.....
...h.
..d".
#####
Plant and chair:
desk http://dl.dropbox.com/u/8446900/game_screen_plant.png
..p...h.
..,...,.
########
The chair is 'h', 'd' is for desk, 'p' is plant, and ',' is for a transparent background tile (no interaction with the user). '"' is for a transparent tile that the user can stand on (extending the desk). The problem is, as you can see, the background appears to have a hole in it.
Should I make an actual tile map and combine everything into one large png? Another option I could take is to actually cut each wide or tall tile into two different tiles. How would a pro do this? I'm not looking for a quick and dirty fix, just how a modern day platformer would run.
UPDATE: After reviewing the answer, I found a very useful tool that packs sprites into a sheet.
http://spritesheetpacker.codeplex.com/
UPDATE: My newly upgraded tile engine is much faster and almost just as simple. The advice below was great. Strongly recommended.
First off - don't introduce special-width/height tiles. Make the artist slice up large objects into single tiles (and hence re-compose them on the map editor). Every tile should be a PNG with an alpha channel so they can be correctly composed.
Keeping that in mind, my recommendations are:
Your tiles should comprise of only single tiles that have pre-composed parts of different objects, for example the left part of the desk is a single tile, the right part without a chair is another and one more with the chair behind it. (tilevalue = "dc", perhaps?)
You can define multiple layers of single tiles and render them back-to-front. You can also define a parallax factor for multiple layers and thus get a nice parallax effect between two layers quite easily. Of course, the player must "exist" in one layer at a time or you won't know what collision geometry to use for his/her current position.
You should also not create one texture per tile - but a compiled tilesheet (exactly like a spritesheet) so that the number of renderstate changes you make are minimized. Making many changes per draw call is bad because each time you make a change (current texture, drawing color or something else that affects that draw call) the API, the driver and possibly the GPU itself has to do work to update its state - this adds up quick.
Note that this doesn't mean you should put characters and levels into a HUGE spritesheet - this is bad for other reasons. You could, for example: put all level-related tiles in one tilesheet, the hero's animation tiles on another and all enemies on one (together) or something similar.
Hope that helps, otherwise I'd be glad to explain things further.
I'm a newbie to 3D on WP7. All I want to do is nice simple 3D
A. Add/Draw a number of coloured primitives, cube and spheres etc. to a 3D world
B. Rotate the World x, y and/or z
That's it, nothing else. I don't need any collision detection, I don't need any clever physics I don't need any textures or backgrounds or anything else, just that nice and simple.
I've been through about a gazillion examples on various websites and they all obscure the basics with bloated code and objects that I just don't want. I don't want any marble or spaceship examples, just some nice clean, clear code.
I have Blender to create the 3D models and these will be simple models with no textures. just solid basic 3D objects.
Please don't point me to anything that's based on a game which every example I have already found is.
Oh and please only examples that actually work.
Well the best way to do 3D on Windows Phone 7 is to use XNA which is generally associated with games which isn't the whole truth. You can still build traditional applications using XNA, although it might take you longer to construct your ui as opposed to silverlight.
You should probably check out App Hub from Microsoft as there are a ton of samples, in fact they have a category specifically for 3D. Keep in mind since your just starting you should make an attempt to understand the examples there giving you. Even though code you see for the first time might seem like bloated or extra code, there actually necessary components to consider when developing 3D applications.
At any rate, this example goes over the basics of 3D using XNA on Windows Phone 7.
EDIT: If you don't want to use XNA, there's this question that was asked previously. There's a couple of solutions for using 3D in silverlight.