In Flixel, you cannot add a FlxSprite to another one, like you could with Flash API (Sprites were subclasses of DisplayObject). So if you want 2 Sprites to behave like parent and child, you still have to animate them separately. This can become a nightmare if you use Tweens too.
For example, imagine a rotating spaceship that has attached thrusters, or a moving character that wears an armor, hat, shield etc.
Is there a way to have a 'child' Sprite acting like it was added into a 'parent' one, so that it updates automatically its position, scale and rotation accordingly? For example, during their FlxGroup's update() function?
I'm interested in HaxeFlixel 3.3.1, although it doesn't really matter, as this applies for all versions and ports of Flixel.
Edit: I noticed that HaxeFlixel features FlxSpriteGroup, which is supposed to handle the multiple Sprites. But this is a new feature, and I'm pretty sure that flixel developers are using different approaches for the rest of the flixel ports.
There's a limited version of this available using: http://api.haxeflixel.com/flixel/addons/display/FlxNestedSprite.html
HaxeFlixel provides FlxSpriteGroup and FlxNestedSprite which both can be used to have some sprites behaving as a group. In both approaches, I had a problem updating the angle and scale properties, however updating the position seems to work fine.
If you are not interested to animate the sprites separately, and painting one sprite over another is what you're after, FlxSprite's stamp() function could be what you need (e.g. draw a helmet over your character)
Related
So, I have been working in Unity but I've decided it's time to change to something I know better: JavaScript. I've been considering switching to Phaser.js but I have some questions regarding an issue I've been having even in Unity and that I found no solution to at the moment while searching on the internet. I have no code to provide as I haven't yet started actually programming in Phaser, so I'll try to be explicit.
My game idea basically revolves around some lights that change colors. The sprites I have for the lights look identical, but just with different colors, but not entirely (only parts of them are colored differently). The problem is that my game has many different colored lights and it has to change between them. Like, if one light is red and you click on it, it becomes green, for example. Creating and loading so many sprites that look almost the same seems like a bad practice, and I wonder if there is a way to change the color of a sprite or a part of the sprite by code. I know that Phaser doesn't support svg and that svg in games is a bad idea in general because of performance issues but it would have saved me a lot of time to just add the generated svg code of the sprites I use and just change the fill of the parts I want.
So, my question is: what are the best alternatives (if any) to using multiple sprites or how can you change the color of specific parts of them?
Another alternative, depending upon your light sprites, is to use Phaser's tinting capabilities.
Both sprites and images in Phaser can be tinted, and since Phaser supports sprite grouping, even if you wanted to change only a part of the image you could easily have each displayed object consist of two sprites, one of which is the same for all lights (the part that doesn't change) and another that is also shared, but tinted.
Phaser 3 example of tinting an image:
this.add.image(300, 300, 'pixel').setTint(0xff0000);
Phaser 3's setTint() documentation.
Phaser 2 CE example of tinting a sprite, in case you're looking at using this version:
sprite = game.add.sprite(game.world.centerX, game.world.centerY, 'atlas', 'greenJellyfish0000');
sprite.tint = Math.random() * 0xffffff;
If the lights don’t have to move, then you can just have a few images and change their src’s. Alternatively, I believe you could have it so that when the sprite is clicked it changes to a different looking animation. That is, after all, the point of a spritesheet, isn’t it?
I'm teaching myself stuff like the astar algorithm, and working with small-ish matrices. To this end, I want to have a direct way of seeding the matrices I'm sending into the function, and I thought a small app that allowed to do limited-color pixel-by-pixel painting would be great.
Basically this: http://www.youtube.com/watch?v=19h1g22hby8
What is a good widget to use, as both the pixels themselves and the canvas for them? I'm very comfortable with QPushButtons and the like, but I'm not that used to a graphics scene. Is that the way to go?
I'd guess something that has built-in methods for detecting when the mouth is hovering on top, and that changes colors quickly... but that makes it seem like a giant QGridLayout with flat QPushButtons might do the trick and yet it seems way unoptimal.
The QGraphicsView with underlying QGraphicsScene would be perfect for this. I would start by adding a whole bunch of QGraphicsRectItem instances to the QGraphicsScene.
Qt does already does drawing, moving and selection of the QGraphicsRectItem instances. You can catch other events, or change the default handling (for example disabling moving), by overriding mouseMoveEvent() and others.
I'm working on an app which needs to draw with OpengGL at a refresh rate at least equal to the refresh rate of the monitor. And I need to perform the drawing in a separate thread so that drawing is never locked by intense UI actions.
Actually I'm using a NSOpenGLView in combination with CVDisplayLink and I'm able to achive 60-80FPS without any problem.
Since I need also to display some cocoa controls on top of this view I tried to subclass NSOpenGLView and make it layer-backed, following LayerBackedOpenGLView Apple example.
The result isn't satisfactory and I get a lot of artifacts.
Therefore I've solved the problem using a separate NSWindow to host the cocoa controls and adding this window as a child window of the main window containing the NSOpenGLView.
It works fine and I'm able to get quite the same FPS as the initial implementation.
Since I consider this solution quite like a dirty hack, I'm looking for an alternative and more clean way of achiving what I need.
Few days ago I came across NSOpenGLLayer and I thought that it could be used as a viable solution for my problem.
So finally, after all this preamble, here comes my question:
is it possible to draw to a NSOpenGLLayer from a separate thread using CVDisplayLink callback?.
So far I've tried to implement this but I'm not able to draw from the CVDisplayLink callback. I can only -setNeedsDisplay:TRUE on the NSOpenGLLayer from the CVDisplayLink callback and then perform the drawing in -drawInOpenGLContext:pixelFormat:forLayerTime:displayTime: when it gets automatically called by cocoa. But I suppose that this way I'm drawing from the main thread, isn't it?
After googling for this I've even found this post in which the user claims that under Lion drawing can occur only inside -drawInOpenGLContext:pixelFormat:forLayerTime:displayTime:.
I'm on Snow Leopard at the moment but the app should run flawlessly even on Lion.
Am I missing something?
Yes, it is possible, though not recommend. Call display on the layer from within your CVDisplayLink. This will cause canDrawInContext:... to be called and if it returns YES, drawInContext:... will be called and all this on whatever thread called display. To make the rendered image visible on screen, you have to call [CATransaction flush]. This method has been suggested on the Apple mailing list, though it is not completely problem free (the display method of other view may get called on your background thread as well and not all views support rendering from a background thread).
The recommend way is to make the layer asynchronous and render the OpenGL context on main thread. If you cannot achieve a good framerate that way, since your main thread is busy elsewhere, it is recommend to rather move everything else (pretty much your whole application logic) to other threads (e.g. using Grand Central Dispatch) and only keep user input and drawing code on the main thread. If your window is very big, you may still not get anything better than 30 FPS (one frame ever two screen refreshes), yet that comes from the fact, that CALayer composition seems a rather expensive process and it has been optimized for more or less static layers (e.g. layers containing a picture) and not for layers updating themselves 60 FPS.
E.g. if you are writing a 3D game, you are advised not to mix CALayers with OpenGL content at all. If you need Cocoa UI elements, either keep them separated from your OpenGL content (e.g. split the window horizontally into a part that displays only OpenGL and a part that only displays controls) or draw all controls yourself (which is pretty common for games).
Last but not least, the two window approach is not as exotic as you may think, that's how VLC (the video player) draws its controls over the video image (which is also rendered by OpenGL on Mac).
I'm building a simple RPG using Pygame and would like to implement a drag-and-drop inventory. However, even with the consideration of blitting a separate surface, it seems that the entire screen will need to be recalculated every single time the user drags an item around. Would it be best to allow a limited range of motion, or is it simply not feasible to implement such an interface?
redrawing most or all of the screen is a very normal thing, across all windowing systems. this is rarely an issue, since most objects on screen can be drawn quickly.
To make this practical, it's necessary to organize all of the game objects that have to be drawn in such a way that they can be quickly found and drawn in the right order. This often means that objects of a particular type are grouped into some sort of layer. The drawing code can go through each layer, and for each object in each layer, ask the object to draw itself. If a particular layer is costly to draw, because it's got a lot of objects, can store a prerendered surface and blit that instead.
A really simple hack to get a similar effect is to capture the screen at the start of a drag to a surface, and then blit that every frame instead of the whole game. This obviously only makes sense in a game where dragging also means that the rest of the game is effectively paused.
There are many GUI examples on pygame.org, as well as libraries for GUIs.
I'm working on a game in XNA for Xbox 360. The game has 3D terrain with a collection of static objects that are connected by a graph of links. I want to draw the links connecting the objects as lines projected on to the terrain. I also want to be able to change the colors etc. of links as players move their selection around, though I don't need the links to move. However, I'm running into issues making this work correctly and efficiently.
Some ideas I've had are:
1) Render quads to a separate render target, and use the texture as an overlay on top of the terrain. I currently have this working, generating the texture only for the area currently visible to the camera to minimize aliasing. However, I'm still getting aliasing issues -- the lines look jaggy, and the game chugs frequently when moving the camera EDIT: it chugs all the time, I just don't have a frame rate counter on Xbox so I only notice it when things move.
2) Bake the lines into a texture ahead of time. This could increase performance, but makes the aliasing issue worse. Also, it doesn't let me dynamically change the properties of the lines without much munging.
3) Make geometry that matches the shape of the terrain by tessellating the line-quads over the terrain. This option seems like it could help, but I'm unsure if I should spend time trying it out if there's an easier way.
Is there some magical way to do this that I haven't thought of? Is one of these paths the best when done correctly?
Your 1) is a fairly good solution. You can reduce the jagginess by filtering -- first, make sure to use bilinear sampling when using the overlay. Then, try blurring the overlay after drawing it but before using it; if you choose a proper filter, it will remove the aliasing.
If it's taking too much time to render the overlay, try reducing its resolution. Without the antialiasing filter, that would just make it jaggier, but with a good filter, it might even look better.
I don't know why the game would chug only when moving the camera. Remember, you should have a separate camera for the overlay -- orthogonal, and pointing down onto the terrain.
Does XNA have a shadowing library? If so, yo could just pretend the lines are shadows.