Making a scrolling floor like in Street fighter 2 in XNA(Monogame) - xna

How would I make a scrolling pseudo 3d floor like in street fighter 2 in XNA(or more specifically MonoGame)?
https://gyazo.com/ea78954a5d96c3cb522eeac4a6ee5f21
for reference, if you aren't aware what I'm talking about. I Understand the concept of how it was done on the SNES(moving each line of the sprite separately) but how could I achieve the same effect in XNA with today's technology and libraries?

What you need is a simple ViewPort.
A ViewPort basically shows only a little scene from an overall bigger Picture. Like you have it in sides crollers or RPGs. You only see the current scene and not the complete Level/World.
An implementation example can be found here:
http://community.monogame.net/t/simple-2d-camera/9135
It might be a bit tricky to understand everything at the beginning, but at the end you can reuse this for almost any 2D game and several effects (camera shake, Rotation and so on) so it's worth the effort,

Related

Making a Platform game with Corona SDK

I'm trying to develop a platform game similar to Geometry Dash but i'm facing a lot of problems during the making of the algorithm.
I don't barely know how to proceed. Are the levels structured with a long image ( that is the ground) with obstacles added, or there are many obstacles generated progressively during the game?
I'd like to know where to start from, what to draw and how to place it in my game, how to build the collision detection.
The game will be an auto-scrolling platformer, so, will the character's asset be moving right or will all the level except for the character be moving left?
I'm a beginner, so i would like to receive detailed answers and not too difficult to understand. Thank you.
if you have any advice I would gladly listen to it.
I've done all corona tutorials but they doesn't explain how to do a platformer. - Luca Pasini
Looks like you still don't feel how game work from inside. Tutorials probably will not help you much. I think you need to start something very simple by your own - not by tutorials.
For example:
Show red rectangle
Show blue recatngle
Tap on the screen and red rectangle must change his position (not by transitions - just by core x,y change)
If they are collide - show text: "You win". Collision check just by raw calculations.
Then go with updates, that will make it looks more like a game.

Split Screen 2 Player Local Multiplayer with SpriteKit

I want to make a 2 player mode, split screen style, like Tiny Wings HD did where each side of an iPad gets a flipped orientation screen of the current Level.
I wanted to also implement it on tvOS (without the flipped orientation) as I feel TV begs for this sort of gameplay as it's pretty classic to have this style of gameplay on TV (e.g. Mario Kart 64 or Goldeneye).
Over on the Apple Developer forum, someone suggested that it could be done as follows, but, there we're no other responses.
"You can have two views attached to the main window (add a subview in your viewcontroller). To both views you can present a copy of the scene. Then you can exchange game data between scenes via singletons."
I was looking for a more in-depth explanation as I don't exactly understand what the answer is saying.
I'd just like to be able to have two cameras both rendering the same scene but one focusing on player 1 and the other player 2.
Obviously this isn't a simple answer, so I don't expect a full in-depth tutorial.
Unfortunately I could find no info on this.
Has anyone tried this?
A sample project would be ideal or some documentation/links that might help.
I'm sure a demonstration of this would be valuable to quite a lot of people.
No Cameras involved or necessary
The players just look like they're moving along the x axis because the backgrounds are scrolling by. You can allow the players to move up & down on the y axis whether jumping, ducking, rolling or following a path like in Tiny Wings, but the player never leaves their x position. You can even have each half of the screen background scrolling at different speeds to represent that one player is moving faster than the other.
In your update method in you scene file you can scroll your backgrounds, and in your touches methods you can jump, duck etc the players
Instead of using an SKView to present an SKScene, you can use SKRenderer and MTKView. SKRenderer renders a scene into a Metal pipeline, which in turn can be presented by an MTView.
Crucially, you can decide if SKRenderer updates the scene, allowing you to render the same scene frame multiple times (possibly using different cameras).
So a pipeline might look like this:
Apple actually talk about this option in Choosing a SpriteKit Scene Renderer. There's also a section about using SKRenderer in Going Beyond 2D with SpriteKit from WWDC17 which is quite helpful. This answer also shows how to use SKRenderer (albeit in Objective-C).

iOS Heavy image switching

I'm developing a app that will showcase products. One of the features of this app is that you will be able to "rotate" the product, using your finger/Pan-Gesture.
I was thinking in implementing this by taking photos of the product from different angles so when you "drag" the image, all I would have to do is switch the image according. If you drag a little, i switch only 1 image... if you drag a lot, i will switch them in cadence making it look like a movie... but i have a concerns and a probable solution:
Is this "performatic"? Since its a art/museum product showcase, the photos will be quite large in size/definition, and loading/switching when "dragged a lot" might be a problem because it would cause "flickering"... And the solution would be: instead of loading pic-by-pic i would put them all inside one massive sheet, and work through them as if they were a sprite...
Is that a good ideia? Or should I stick with the pic-by-pic rotation?
Edit 1: There`s a complicator: the user will be able to zoom in/out and to rotate the product in any axis (X, Y and Z)...
My personal opinion, I don't think this will work the way you hope or the performance and/or aesthetics will not be what you want.
1) Taking individuals shots that you then try to keyframe to based on touch events won't work well because you will have inevitable inconsistencies in 'framing' the shots such that the playback won't be smooth
2) The best way to do this, I suspect, will be to shoot it with video and shoot it with some sort of rig that allows you to keep the camera fixed while rotating the object
3) I'm pretty sure this is how most 'professional' grade product carousel type presentations work
4) Even then you will have more image frames than you need -- not sure whether you plan to embed the images files in app or download on demand -- but that is also a consideration in terms of how much downsampling you'll need to do to reduce frames/file size
Suggestion
Look at shooting these as video (somewhat like described above) and downsampling and removing excess frames using a video editor. Then you could use AVFoundation for playback and use your gestures to 'scrub' into the video frames. I worked on something like this for HTML playback at a large company and I can assure you it was done with video.
Alternatively, if video won't work for you. Your sprite sheet solution might work (consider using SpriteKit). But then keep in mind what I said about trying to keyframe one off camera shots together -- it just won't work well. Maybe a compromise would be to shoot static images but do so by fixing the camera and rotating the objects at very specific increments. That could work as well I suppose but you will need to be very careful about light and other atmospehrics. It doesn't take much variation at all to be detectable to the human eye causing the whole presentation to seem strange. Good luck.
A coder from my company did something like this before using 360 images of an object and it worked just great but it didn't have zoom. Maybe you could add zoom by adding a pinch gesture recognizer and placing the image view into a scroll view to zoom in on the static image.
This scenario sounds like what you really need is a simple 3D model loader library or write it in OpenGL yourself. But this pan and zoom behavior is really basic when you make that jump to 3D so it should be easy to find lots of examples.
All depends on your situation and time constraints :)

UIScrollView Dome Effect

DESIRED EFFECT:
Imagine a UIScrollView such that as you scroll in any direction, you feel like you're looking around inside a dome. As in, the screen is stretched/warped/distorted at the edges by a filter/mesh of some sort. Think of a 3D game where you're looking up at the sky.
WHAT IT'S FOR:
I plan on plastering menu items on a sky of sorts. Imagine looking at the sky where clouds are tappable menu items and there are enough clouds such that you have to scroll around to find them all. This is just a menu to the actual content; it isn't a full 3D game where you can move around and such. I am therefore hoping that I can fake the 3D effect by stretching/warping/distorting the edges of the screen.
WHAT I NEED:
I need to at least know the direction to look in so that I can see how feasible and how much work it will take. If it's too much, I'll unfortunately have to do something else.
From what I've looked at so far, it appears that QuartzCore isn't enough and I suspect that OpenGL is the only way to do it. Before I throw myself into OpenGL though (I'm a complete noob at it), I'd like to know if that's even the correct technology that I should be looking at. And if it is, what area of it I should be looking at (initial searches indicated stuff like texture warping might be what I'm looking for?).
Thanks!
You’re on the right track. You’ll want to use OpenGL ES for this. The basic idea behind this that I’ve seen used to great effect is to project the scene on the inside of a cube, rotating the cube when the user moves their finger. This book really helped me when I got started with OpenGL.

Cocos2d: graphics tool

I started to learn Cocos2d to develop games and also Box2d; I read some tutorials and I seen that are used two couples of tool "LevelHelper-SpriteHelper" & "PhysicsEditor-TexturePacker".
I noticed that LevelHelper-SpriteHelper are more "simply" and organize levels and physics objects very well.
While with PhysicsEditor-TexturePacker I noticed some difficulties where the approach is not very clear.
So what are the best tools between "LevelHelper-SpriteHelper" & "PhysicsEditor-TexturePacker"?
And what are the differences? Can you explain me? thanks
This should answer your questions: http://abitofcode.com/2012/07/cocos2d-useful-tools/
Physics editor is a program that you use to create a tracing around a sprite that isn't a simple polygon. For example it could trace an image of a car, so that when you went to detect a collision between your car and another object with a physics engine (something like box2d) it registers a collision just with the car and not a square surrounding the car. Here is a picture that shows you what it does: http://www.codeandweb.com/physicseditor/features.
Texture-packer is used to put all your sprites that you use in your game into one spritesheet. This allows you to minimize the amount of memory that all of your sprites take up.
http://www.codeandweb.com/texturepacker That picture shows you what it does. Instead of having to add all your individual sprite images to your game you put them all on a spritesheet, which trims the space around each image and puts it into a file size that cocos2d and the iphone can work with.
This is helpful because cocos2d only takes images that have dimensions to the power of two. (2,4,8,16....) If you had a sprite that was 50x50, it would actually take up 64x64 amount of space in your game.
Here is a tutorial that explains most of that better than i did: http://www.raywenderlich.com/2361/how-to-create-and-optimize-sprite-sheets-in-cocos2d-with-texture-packer-and-pixel-formats
And here is project where both are used: http://www.raywenderlich.com/7261/monkey-jump
And here is one with levelhelper and spritehelper: http://www.raywenderlich.com/6929/how-to-make-a-game-like-jetpack-joyride-using-levelhelper-spritehelper-part-1
For a list of more tools go here"
http://www.learn-cocos2d.com/2011/06/complete-list-cocos2d-tools/
SpriteHelper is essentially the same tool as TexturePacker. Both create a single large texture from individual images.
LevelHelper is an editing tool to design your game visually. It also allows editing of the physics world.
PhysicsEditor is a tool to create the (collision) shapes of physics bodies from images. No more, no less.

Resources