Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dutrius]

I haven't actually started yet, thankfully. I am, however currently wrapping my head around the sort of interface it would use. Or at least trying to.

I don't even have an iPad.

[Reelya]

You could build a roguelike in Unity, push it to both iOS and Android. It might not be as lightweight as a native app, but you have the cross-platform thing fully covered. You also have the advantage that you can prototype your whole thing on PC then, and worry about platforms (or porting) later once you at least have a playable concept. Unity 5 is completely free to dev and release games, I think you only need to buy a license if you make $100,000 per year off your games.

[MorleyDev]

You can actually coerce both C++ and .NET (so C#) into running on Android and iOS. I suspect most big cross-platform 2D games are based in MonoGame via Xamarin (Towerfall, for example).

SDL2 and SFML both have iOS and Android support (experimental for SFML though), and you can go all out and use raw OpenGL on all of those if you know what you're doing.

There is also HTML5, so (Java/Type/Coffee)script and Canvas, which will run on Android and iOS and can be wrapped up and turned into applications. Heck, if you wanted to be utterly insane you could compile SDL2 + C++ into HTML5 via Emscripten.

Basically the options are there, so if you pick a tool and google a bit you may be able to find out how to mobileify it with some elbow grease

[Hugehead]

Android apps are written in a specific variety of Java. I don't know about iOS apps, but you'd have to pay to get one onto the app store anyway.

Yes,  but the actual drvice, under that, runs a flavor of Linux, right?

E-eh. I don't know if I'd go that far (UNIX might be more accurate), because whilst I think it may be true in the strictest sense it's probably about as closely related to common distros of Linux as MacOS or whatever Macs run is.

It's possible to play DF on a tablet if you SSH into a PC, though.

It's worth a shot though.

Android does run a modified version of the Linux kernel, but this doesn't make it very similar to the GNU/Linux systems you may be familiar with. Above the kernel Google have their own libraries and API, which lack some features necessary in GNU/Linux systems. Further, on top of the libraries Android has a custom built Java virtual machine where userspace applications you run live. There are some tools to build native code for Android that you can call from the JVM, but due to the nonstandard libraries I don't believe it's as simple as just compiling your existing code using the tools. Note that I am no expert in Android development, especially regarding native code, but I think this is fairly accurate.

[miauw62]

there is, however, nothing stopping you from installing, like, debian on your android phone or whatever. because apple a shit you should give up all hope of running it on a phone or tablet made by apple, though.

[Dutrius]

I don't even have an iPad.

[Gatleos]

So today I went back to a programming problem I haven't considered for a long time: collision handling. Disregarding the math involved in just detecting a collision between two objects, what's the usual OOP method of handling the behavior of many different combinations of object types that could be colliding? I'm working in c++, so my first instinct was of course to use inheritance of some kind. This leads to an abstract class something like this:

Code: [Select]

class Collider {
public:
Rectangle bounds;
virtual void onCollide() = 0;
};
Then I can have data structures like Quadtrees that help me efficiently determine which objects to collide, and populate it with pointers to Collider-derived objects. The problem, of course, is that the main requirement of collision handling is that I know what type both objects are. My handy virtual function lets me define behavior based on what this object is, but what about the other one? The best I can accomplish with this model is

Code: [Select]

virtual void onCollide(Collider& c) = 0;...Which doesn't tell me much at all.

The inheritance system in c++ doesn't seem to be equipped for this kind of thing; it seems that any solution which takes many types into account starts to defeat the purpose of using inheritance at all. Everything I try seems to end up as a mess of redundant definitions, and the combinatorial explosion will kill me later on if I'm not careful.

[Bauglir]

I'll be honest, I have no idea what the standard approach would be, but if it were me I'd construct some larger container that contains information about every object that can collide, does collision detection, and calls each object's internal collision response function when one happens. To the extent that each object needs to know things about the other, it may also call various getters prior to calling the collision response functions.

of course i think there's a lot of equivocation around the word "object" in what i just wrote but hopefully it is effective?

[monkey]

Double/Multi dispatch or the visitor pattern.

Code: [Select]

class Triangle;
class Circle;

class Shape {
public:
  virtual void onCollide(Shape* other) = 0;
  virtual void collide(Triangle*) = 0;
  virtual void collide(Circle*) = 0;
};

class Triangle : public Shape {
public:
  virtual void onCollide(Shape* other) { other->collide(this); }
  virtual void collide(Triangle*) { std::cout << "triangle-triangle" << std::endl; }
  virtual void collide(Circle*) { std::cout << "circle-triangle" << std::endl; }
};

class Circle : public Shape {
public:
  virtual void onCollide(Shape* other) { other->collide(this); }
  virtual void collide(Triangle*) { std::cout << "triangle-circle" << std::endl; }
  virtual void collide(Circle*) { std::cout << "circle-circle" << std::endl; }
};

int main()
{
  Shape* c = new Circle();
  Shape* t = new Triangle();

  t->onCollide(c);
  t->onCollide(t);
  c->onCollide(c);
  c->onCollide(t);
  return 0;
}


[Putnam]

What are you doing?

[Rose]

Learning  how to program using graphics.

Hahahahahaha no.

I've done quite a bit of programming, but raw opengl is still techno-voodoo for me.

[EnigmaticHat]

Learning  how to program using graphics.

Use SDL and keep it 2D

[Moghjubar]

Learning  how to program using graphics.

Hahahahahaha no.

I've done quite a bit of programming, but raw opengl is still techno-voodoo for me.

If you really want to learn OpenGL, theres some pretty good tutorials out there.  NeHe is pretty amazing: http://nehe.gamedev.net/

You'll eventually need to look at the specs (pdf files), and look at the redbook http://www.glprogramming.com/red/
I had another good source but it page-sploded.  In any case, I honestly didn't think it was that rough, once you got started (though I'm nowhere near an amazing expert on it now, for sure; I just generally know how to do things like draw stuff, 3d math, shaders, VBO, etc).

[alway]

OpenGL it is then.
Things to know:
Shaders are programs run by the GPU.

There are two main flavors of shaders when starting out:
    Vertex Shaders which deal with mathematically putting your points (vertices) into place.
    Pixel Shaders which deal with coloring the pixels of your triangles.

You feed the GPU a bunch of vertex data containing info about your vertices (aka points; but always called vertices), as well as a bunch of other data in textures or buffers.

The GPU transforms this data using the set Vertex Shader (you will generally define this) into the points used for rendering to the screen. Usually involves transformation matrix or two which turn your 3D coordinates into 2D screen coordinates.

The GPU then uses these points either on their own or with a buffer of indices into the vertex data to figure out which vertices go together to form your triangles. It fills in all of the pixels within said triangles, so long as they are going to be on screen.

The GPU then goes through each pixel and runs the Pixel Shader (you will generally define this) on each of them. The inputs for this come from the outputs of your earlier Vertex Shader and any other textures/buffers you sent it. Inputs for a pixel from a vertex shader output will be linearly interpolated across the surface of the triangle, based on how far it is from the 3 vertices making up the triangle.

The final pixel colors go into a screen buffer, and when you're done, you swap (aka Present) that buffer with the one being displayed.

These are the core ideas to start out with. All the rest is (necessary) bureaucracy managing the fact that the GPU is essentially a second computer you're controlling over a specialized 50GB/s, 4 inch long network. This results in making sending data and programs (shaders) to the GPU and getting everything set up seem a bit long-winded the first time.

GLHF.

[Orange Wizard]

Let's be honest, there's basically no reason why someone would want to write their own rendering code instead of using an existing wrapper or engine, other than learning or a masochistic desire for utmost efficiency.