nicee 

Hi

I would argue against using Unity. It is bloated, slow, crashes all the time, plus you would have to throw out the app that you already have and rewrite EVERYTHING from the start.

"I would like to install exactly this real city view and thus replace the ListView."

If you don't want fancy animations, then the simplest thing is to put the background on an image, then put the available buildings with transparent backgrounds on that image too. If you have 15 possible buildings, this means merging 16 images in worst case. Then it is simply a matter of using an ImageView instead of a ListView and you're good to go, and you can keep your current code base.

If you want fluent animations, then yes, you'll have to get your hands dirty with GLES (the dialect of OpenGL that Android speaks). You'll have to build a list of coordinates for quads (boxes) that maps specific parts of your texture (image) to the screen, so each coordinate contains two screen coordinates (x,y) and two texture coordinate (u,v). For a quad, you'll have four of these, one for each edge.

In that list, the very first quad will be the background (with screen coordinates 0,0 - screen width, screen height), and with a fixed texture coordinate. There should be as many other quads as many buildings you have. Here x,y will be the screen position where you want to display the building, and width and height is the size of your building image, and u,v is set to a coordinate on your texture (image) where the building's image is. To make it animated, at regular intervals you'll have to replace the texture u,v coordinates so that they point to the next animation frame on your texture image.

Alternatively if you don't have many animation frames and you're good with low FPS for the animation, then you could try to use ImageSwitcher. It's not as elegant solution as with GLES, but you should be able to use it with your current programming skillset.

Cheers,
bzt

@bzt I am pretty sure evelynchurch is a spambot. this thread is four years old.

this has been happening alot lately.

@Ragnar Random: oh, I haven't noticed. Good to know, thank you very much for the heads up!

Regardless, my advice to @Samko stands, I would start with a still city view and I would study ImageView if I were in his shoes. I've found this Android example on how to merge images, however it is wrong. The correct way to calculate the new pixels is:
int a = Color.alpha(p2);

r = (r2*a + (256-a)*r)/256;
g = (g2*a + (256-a)*g)/256;
b = (b2*a + (256-a)*b)/256;

operation.setPixel(i, j, Color.argb(255, r, g, b)); // no alpha on city view

Otherwise this code demonstrates how to merge images (which you have in .png) into a new image (which is going to be the city view and should be passed to ImageView) on Android.

I hope this is still going to be useful for someone searching the OGA forums, even if @Samko isn't around anymore.

Cheers,
bzt

yah i agree with your advice in re unity as well. it is a bloated turd.

but i know people who swear by it, so to each their own.

i have no interest in ansi c and doing the type hardcore coding that you are into, so we all gotta do our own thing i spose

"but i know people who swear by it, so to each their own."

They can swear by it as mush as they like, the issue with Unity is that 99% of the games written in it are literally unplayable. About 40% of the Unity games I've downloaded from itch.io are crashing or producing some unrecognizable artifact on screen (sometimes even crashing the entire graphical session, not just the game), about 59% starts and display their window correctly, but are so laggish and slow that it is impossible to enjoy them, and only 1% is that you can actually play (there's no relation between the game's complexity and the lag, some pretty simple 2D games are lagging badly but some very complex 3D ones not).

Another very serious issue that Unity games aren't multiplatform, despite they are supposedly using C# bytecode. I've also tried to run them with a native Linux Unity executable from another game, but many are using a special that-game-only executable which means I'm forced to use wine. (It doesn't matter if the engine is allegedly multiplatform, if the games are shipping only a Windows executable, and nothing else works with them.)

For the records, I don't have a top-shelf gamer PC, but I can run non-Unity games without problems or lag (both Linux native and Windows native through wine), so the problem is in the Unity engine for sure.

Cheers,
bzt

1. The pictures from the thread start look extremely cool.

2. Ragnar Random is right that we all choose our own coding style/approach. I'm a hardcore coder with C and such, similar to bzt. But as Ragnar said: Each his own. (I just recently found out that PHP is not as bad as I used to think.)

"The pictures from the thread start look extremely cool."

Indeed! It's a shame if he hasn't finished the game because nobody could help him in time. I really do hope he hasn't given up!

"Ragnar Random is right that we all choose our own coding style/approach."

On that we all agree. But what I'm trying to say is, this isn't a question of coding style/approach, it's a matter of usability. The low ratio of smoothly running and bug-free Unity games tells me that it requires lots of skill and experience to use Unity correctly, so despite the ads, maybe Unity isn't the right tool for the casual game creators. IMHO, strictly based on my bad experience with Unity games as an end-user.

"I just recently found out that PHP is not as bad as I used to think."

Yeah, PHP is a very sharp real swiss-army knife, damn easy to cut your fingers with it. Not sure if you can compare a programming language with a game creation framework though. But let's assume you can, I wouldn't recommend programming in pure PHP for occasional website builders either, because it is almost certain they would just create yet another load maximizer monster with a miriad of security holes.

Cheers,
bzt