How it works in reMOM is basically this:
The uilogic has a currentscreen reference. it uses it to draw the screen. It has a subscription to an event of the base screen class. Whenever the base screen class raises the event, uilogic will swithc screens(which includes unsubing/resubing, and initializing the new screen).
The new screen has an identifyer that is a parameter of the event. The logic will shift trough the available screens and find the one using the same ID, and switch the current screen for that one. If it fails to find one, it throws up.
So basically, the old screen tells the logic: im done, go for X. The uilogic then grabs X from its pool of screens.
Thanks, I figured it out last night. Just need to call "OnScreenChange(Screen, object)" function to change to another screen.
Just one more thing then I'm set: How to reference one image's palette for another image? It seems like some images depends on the first image's palette. I got the general gist of how it loads palettes into a Palette class, but need to point to that particular class for some images.
Also, I'm not using Ninject, so some things will be done a bit differently.
Dominus Galaxia, a Master of Orion inspired game I'm working on.
I have a cache for palettes. Whenever I create a palette texture, I add it to the cache if it doesnt contain it. If it does contain it, then I simply return that one.
So basically any palette is only created once. I use MD5 to differentiate palettes, (tough I already had 2 palettes end up the same hash)
Then I have an overload for drawimage, that takes a palette name as a parameter. I wrote a shader that uses the palette texture to mimic indexed images. You can set the palette as a textureunit. Grab the palette you want, and youre set.
What are the galaxy sizes in MoO 1? I'm not referring to "Small, Medium, Large, Huge", I'm referring to the grid size (30x30?)
Maybe I should start four different games, one for each size, using the same options for everything else, and compare the save files and see if I can find out.
Has anyone had any luck figuring out how MoO generates its galaxies?
One thing that I've thought about: Adding the ability of having all races in MoO participate in a game at once. There are some problems with this:
1. There are only 6 colors, with ship arts for each color. There are 10 races in MoO, so we'd need to re-use 4 of the 6 colors, or create new artwork/colors. Many aspects of game uses one of six colors (the losing screen for example)
2. Diplomacy screen only supports 5 races (I could add next/prev buttons to go to next screen)
3. Spying is set up so you can spend up to 10% of your income per race, plus 20% for defense, for total of 70%. With max of 9 other races, it'd have to be capped at 50% for all 9 races
4. The galaxy would feel cramped with all 10 races competing for space.
#4 brings up a possibility: Add larger galaxy sizes (Epic, Ludricious, etc) This is easily done, but there's some more problems:
1. The map overview have four different "box" art, for each size. I'd have to manually scale the box art to match the galaxy size
2. End game may get drawn out due to more stars
3. Harder to navigate around the map due to its size. I could implement zooming in/out similar to Beyond Beyaan to resolve this problem.
4. Perhaps some other unforeseen problems?
Again, I don't want to massively change how MoO works, but I would like to expand on what it have already (more races playing at once, etc). What are your thoughts on this?
Dominus Galaxia, a Master of Orion inspired game I'm working on.
Sorry I've been away for so long; I've been having some health issues (possibly migraine-related) that seem to get worse when I spend much time looking at a computer screen, which has limited my time both online and playing computer games. Since the problem is ongoing and I don't know when/if it will really be resolved, I doubt if I'll be able to test my galaxy-creation theories any further than I have, so I figured I'd post what I've got so far, in case it's helpful. (It looks like quite extraordinary progress has been made in other ways since I've been gone though anyway -- I'm really impressed with the LBX reverse-engineering work! -- and it may be that this theory has been effectively proven/disproven or obviated.)
So: My starting hypothesis was that the question of how maps get built was related to the curious way in which Orion numbers stars in-game: While the star numbers progress more or less from the northwest corner of the map toward the southeast corner, a star "later" on the list sometimes appears north, west, or even north and west of a star "earlier" on the list. This implies to me that the star numbers are not determined by their positions (or anything else) after the map has been generated, but rather that map-generation itself is handled star by star in numerical order.
Specifically, I'm guessing that the stars are placed in a kind of grid with overlapping cells: Preliminary testing suggests that Small galaxies are built with four potentially-overlapping "rows" of six stars each, Medium galaxies consist of six "rows" of eight, etc. (I think Large galaxies feature eight "rows" of ten, and Huge galaxies feature ten "rows" of twelve, but I haven't explored those closely, so that's mostly extrapolation; I may not even have the right number of stars for those galaxy sizes, though of course that can be checked easily.)
I was hoping to do more testing to find the actual values of the width and height of each cell, and the vertical and horizontal offsets between them, but got floored by these health issues before I was able to test them adequately. My ballpark guess is something like 6 parsecs each for width and height, with a 3 parsec offset between cells. (Thus, star number 1 could be anywhere within a square with corners at 0.1,0.1 and 6.0, 6.0; if I remember correctly, star locations are always expressed in tenth-of-a-parsec coordinates.)
Based on the way Orion handles other things, I suspect that it also automatically rerolls the coordinates of any star that's "too close" to either the star that immediately precedes it in its "row" or the star that occupies the same horizontal "slot" in the row above it. (Possibly it also checks the star in the cells just northwest and northeast of it; not sure.) The minimum distance between stars might be 3 parsecs as well; stars can appear closer together, but I suspect this happens when (say) star 1 is near the eastern edge of its cell and star 3 is nearly the western edge of its own. (Likewise possible for stars two "rows" apart, of course.) That's pure speculation on my part at this point though.
(There may also be a "too far" reroll; I'm just not sure at all of how it works, if so, as it's one of the things I haven't had time to test.)
Hopefully this is semi-useful. And if I'm clearly wrong for any reason, please do post and say so (and how/why that's the case)!
In case an example of what I'm talking about would be useful, here's one for a small galaxy (in spoiler tags for size and code tags to preserve the monotype table). Note again that all specific numbers are arbitrarily selected by me to get into the right ballpark and give the general impression of what I mean; it's imaginable that they may even be correct, but they're not actually tested against anything.
Code:
star # x coord y coord
1 0.1-6.0 0.1-6.0
2 3.1-9.0 0.1-6.0 (reroll if too close to star 1)
3 6.1-12.0 0.1-6.0 (reroll if too close to star 2)
4 9.1-15.0 0.1-6.0 (reroll if too close to star 3)
5 12.1-18.0 0.1-6.0 (reroll if too close to star 4)
6 15.1-21.0 0.1-6.0 (reroll if too close to star 5)
7 0.1-6.0 3.1-9.0 (reroll if too close to star 1)
8 3.1-9.0 3.1-9.0 (reroll if too close to stars 2 or 7)
9 6.1-12.0 3.1-9.0 (reroll if too close to stars 3 or 8)
10 9.1-15.0 3.1-9.0 (reroll if too close to stars 4 or 9)
11 12.1-18.0 3.1-9.0 (reroll if too close to stars 5 or 10)
12 15.1-21.0 3.1-9.0 (reroll if too close to stars 6 or 11)
13 0.1-6.0 6.1-12.0 (reroll if too close to star 7)
14 3.1-9.0 6.1-12.0 (reroll if too close to stars 8 or 13)
15 6.1-12.0 6.1-12.0 (reroll if too close to stars 9 or 14)
16 9.1-15.0 6.1-12.0 (reroll if too close to stars 10 or 15)
17 12.1-18.0 6.1-12.0 (reroll if too close to stars 11 or 16)
18 15.1-21.0 6.1-12.0 (reroll if too close to stars 12 or 17)
19 0.1-6.0 9.1-15.0 (reroll if too close to star 13)
20 3.1-9.0 9.1-15.0 (reroll if too close to stars 14 or 19)
21 6.1-12.0 9.1-15.0 (reroll if too close to stars 15 or 20)
22 9.1-15.0 9.1-15.0 (reroll if too close to stars 16 or 21)
23 12.1-18.0 9.1-15.0 (reroll if too close to stars 17 or 22)
24 15.1-21.0 9.1-15.0 (reroll if too close to stars 18 or 23)
VM Wrote:Not trying to tell you how to do your sruff, but why arent you using ninject?
Because I haven't had experience using ninject. A quick look through their website, it seems like a tool that makes your projects more OO? I don't really see an use for it.
Dominus Galaxia, a Master of Orion inspired game I'm working on.
I had to tweak the code a bit to get the palettes loaded from image files into "ExtraPalettes", so I can just tell it to use an image's name and it'll grab the palette.
It works beautifully, however, there's a problem. I draw the ship background for the main menu, then the game's title on top. Without the palette swapping, things looks fine, except for rainbow colored title. With the palette swapping, the title looks correct (grey), but no transparency for the black pixels, so it's just a black screen with the title.
What am I doing wrong?
Edit: I've uploaded teh latest code, so you can take a look at my code and see how it works.
Dominus Galaxia, a Master of Orion inspired game I'm working on.
