Since a large number of models are random rotating, which way can control the rotation most efficiently? Is it to bind the scripts on each model with rotation in the update?
PS:We encounter some problems when using the untiy3d engine. We use the version: 3.5.0 and the Ellipsoid Particle Emitter of the Legacy Particles with ios target platform.
Creating a prefab with the model and script is the most common and possibly most efficient way to populate your scene with many similar objects.
You can use Update() to control it, but you should use FixedUpdate() to deal with physics stuff.
You could also have a script - in another game object that would only be a container for this script - to instantiate those asset objects instead of drag & dropping each one, if the number of objects is big enough to compensate for the work.
Explain:
Are Random models same in body texture and other attributes?
If yes,
then can help you Instantiating prefabs this and you can help you can just drag and drop code of rotation on one enemy and prefabs can access it randomly or you can also by making rotation rate public.
It will all depend on your code logic afterwards.
Related
I want to make a pool game where the user can pinch the pool table to zoom so he can
precisely shoot the pocket.
So, this means I need a large pool table graphic.
What is the best way to handle such a situation in cocos2d?
How do I load the graphic? What is the limitation on graphic size?
I have a lot of doubts because Im not sure which path to take.
Regards
Mirza
For something as simple as a pool table it might be better to render it all using vector graphics. This means you will need less graphics (perhaps only a few for textures) and you get infinite zooming without all the graphic image overhead.
I want to use OpenGL ES to scale and display an image on the screen. The image is going to be updated about 20 times per second, so the idea was to paint directly into the texture. While scaling should be done by the graphic card, the pixel format is guaranteed to be in the correct format by my application. My application needs to manipulate the image on a pixel-by-pixel basis. Due to the architecture of the application I would like to avoid calls like settexel(x,y,color) but write directly into memory.
Is it possible to directly access a texture in the (graphic card's?) memory and change it pixel-wise?
If not, is it possible to use something like settexel(x,y,color) to change a texture?
Thanks for any help!
Ok, after asking some guys at my company I found out that there is no clean way to access the graphic memory directly (solution 1) or to access the main memory from within a shader (solution 2).
Thus, I will store the pixels in the main memory and move the changed regions via glTextSubImage2D into the graphic memory.
Thanks to everybody who helped me with this!
I am making my first program using Java3D. I have setup some transformGroups that I now need to move in calculated directions. When I looked this up, I found interpolators and alpha objects and waveforms and couldn't understand a word of it. I have done this in the past in OpenGL using simple vectors and frame refreshment. Is there a similar simple way in Java3d? Thanks.
There's no reason you couldn't do it with vectors and frame refresh in Java3D as well.
A simple way would be to attach a behavior to the scenegraph with a WakeupOnElapsedFrames(0) condition, and then have it update the needed transform every frame.
As its simplest, that is was the interpolators are doing for you. Once you get that working, it will probably make more sense as to how you could do it with interpolators.
I am working through Aaron Hillegass' Cocoa Programming for Mac OS X and am doing the challenge for Chapter 18. Basically, the challenge is to write an app that can draw ovals using your mouse, and then additionally, add saving/loading and undo support. I'm trying to think of a good class design for this app that follows MVC. Here's what I had in mind:
Have a NSView-subclass that represents an oval (say JBOval) that I can use to easily draw an oval.
Have a main view (JBDrawingView) that holds JBOvals and draws them.
The thing is that I wasn't sure how to add archiving. Should I archive each JBOval? I think this would work, but archiving an NSView doesn't seem very efficient. Any ideas on a better class design?
Thanks.
Have a NSView-subclass that represents an oval (say JBOval) that I can use to easily draw an oval.
That doesn't sound very MVC. “JBOval” sounds like a model class to me.
Have a main view (JBDrawingView) that holds JBOvals and draws them.
I do like this part.
My suggestion is to have each model object (JBOval, etc.) able to create a Bézier path representing itself. The JBDrawingView (and you should come up with a better name for that, as all views draw by definition) should ask each model object for its Bézier path, fill settings, and stroke settings, and draw the object accordingly.
This keeps the knowledge of how to draw (the path, line width, colors, etc.) in the various shape classes where they belong, while also keeping the actual drawing code in the view layer where it belongs.
The answer to where to put archiving code should be intuitively obvious from this point.
Having a whole NSView for each oval seems rather heavyweight to me. I would descend them from NSObject instead and just have them draw to the current view.
They could also know how to archive themselves, although at that point you'd probably want to think about pulling them out of the view and thinking of them more as part of your model.
Your JBOval views would each be responsible for drawing themselves (basically drawing an oval path and filling it, within their bounds), but JBDrawingView would be responsible for mousing and dragging (and thereby sizing and positioning the JBOvals, which would be its subviews). The drawingView would do no drawing itself.
So far as archiving, you could either have a model class to represent each oval (such as its bounding rectangle, or any other dimensions you choose to represent each oval with). You could archive and unarchive these models to recreate your views.
Finally, I use the JB prefix too, so … :P at you.
I would like to create a custom NSView that takes a layered approach to painting. I imagine the majority of the layers would be the same width and height as the backing view.
Is it appropriate to use the Core Animation classes like CALayer for this task, even though I don't expect to need much animation? Is there a more appropriate approach?
To clarify, the view is not meant to be like a canvas in a Photoshop-like application. It more of a data display that should allow for user interaction (selecting, moving, scrolling, etc.)
If it's display and layout you're after, I'd say that a CALayer-based architecture is a good choice. For the open source Core Plot framework, we construct all of our graphs and plot elements out of CALayers, and organize them in a regular hierarchy. CALayers are lightweight and use almost identical APIs between Mac and iPhone. They can even be made to respond to touch or mouse events.
For another example of a CALayer-based user interface, my iPhone application's entire equation entry interface is composed of CALayers, including the menu that slides up from below. Performance is slightly better than that of my previous UIView-based implementation, but the same code also works within my preliminary desktop version of the application.
For a drawing program, I would imagine it would be important to hold a buffer of the bitmap data. The only issue with using a CALayer is that the contents property is a CGImageRef. To turn that back into a graphics context for doing further drawing can be a bit of a pain. You'd have to initialize a new context, draw the bitmap data into it, then do whatever drawing operations you wanted to do, and finally turn that back into a CGImageRef. You probably wouldn't be able to avoid doing a number of pretty large memory allocations, which is virtually guaranteed to slow your program way down.
I would consider holding an off-screen buffer for each layer. Take a look at the Quartz CGLayerRef object. I think it probably does what you want to do: it's an off-screen buffer that holds things you might want to draw repeatedly. You can also quickly get a CGContextRef whenever you need it so you can do additional drawing. And you can always use that CGContextRef with NSGraphicsContext if you want to use Cocoa drawing methods.