Development:Base Backgrounds

From VsWiki
Revision as of 05:49, 24 May 2008 by Nachtwolf (talk | contribs) (→‎Python Scripts: info about Z coordinate of ships)
Jump to: navigation, search
thumb_arrow_up.png Development

Introduction

This page summarizes concepts and approaches recommended to add base or planet backgrounds to Vega Strike.

Development Needs and Tasks

We could always use more backgrounds. Ideally, each planet and base in Vega Strike would have a unique background.

Please head over here for a list of open tasks: Development:2D_Images#Base_Backgrounds

Docking Backgrounds

Texture Requirements

Generic Image Requirements

Please read this Development:Graphics_Requirements page before continuing to the specific requirements.

Specific Image Requirements

That leaves few options:

  • 1024x1024
  • 2048x2048

Keeping original high resolution image (e.g. 8192x or 4096x) versions in stock helps maintaining quality and scalability as game development progresses or typical screen resolutions rise in the future with better hardware available to the players.

Creating and Naming

Comments by MamiyaOtaru in Forums

First off, the bases are not full screen due to the config file, not the sprite file. Change that first to have fullscreen bases. So, the explanation:

In the coordinate system, 0,0 is at the center not the top left. The coordinate system is cartesian, left to right is -1 to 1 x, top to bottom is 1 to -1 y.

Width 2 means the width of the screen (two halves, from -1 to 1) and height 2 means the height of the screen.

In your example, the image is meant to take up 3.104/2 screen widths and 2.4832/2 screen heights. This is because the actual used part of the image (320x200) is approx 512*(2/3.2) x 256*(2/2.5). 3.104 and 2.4832 stretch the image beyond fullscreen, so that the part of the image that actually has something in it (which is only 320x200) will take up fullscreen.

The next two numbers are where the image is centered. Often, those two numbers are actually stored elsewhere. In cockpits, they are stored in the .cpt file and only the dimensions are actually in the .spr file. Here, the X and Y coordinates for the center of the image are in /bases/*.py. Your example is in /bases/pleasure_land.py

Your example is therefore actually 3.104 2.4832 width and height and 0.582 -0.2716 centerX and centerY

The center of the image is thus a little more than half the distance from the center of the screen to the right hand side of the screen. This serves to place the center of the area that has actual content at the center of the screen. The center is a bit more than a quarter of the way from the center to the bottom of the screen for the same reason.

If you use an image that fills up the whole bitmap, without empty space like the priv remake backgrounds, to go fullscreen you would use something like this 2 2 (2 half widths and half heights, from -1, -1 to 1, 1) 0 0 (centered in the center of the screen)

Oh, and pleasure_land.py is also where the animations are linked, if you'd like to remove them for a different background. The animations are the water and the building lights: Jolson_LandingBay_wtr and Jolson_LandingBay_blt respectively. Remove their lines.


Python Scripts

You will need to create the appropriate python scripts to be placed in the bases directory.

Each planet has a script labeled according to its texture name (i.e. texturename_day.py, texturename_night.py, texturename_sunset.py, etc.) What this means is that each planet you want specific control over will require its own texture. Not too big a task (as I assume the number of planets for which this control is needed is not major), as you can almost just copy and paste the old python files for the planet type, but you will also need to edit units.csv to add that planet type. This is easy if you know what you're doing, but obviously is not a long term solution to such a problem. (If anyone knows of a better way that we can do this, let me know!)

Each unit type has a script labeled according to its unit and faction name (unitname_factionname.py, or ignoring factions unitname.py). Here the trick will be to create a python file that checks the name of the unit you are docked to to see if it's the campaign one. If it is then do something special, else do the same as every other unit.

Basically, these scripts are simply run when the player docks. We can't force a different script to load at will, only make sure that the script VS looks for contains what we want it to. However, it might be useful in future to change this...

Room definition 

room1 = Base.Room ('Aera Planet')
Base.Texture (room1, 'tex', 'bases/generic/aera_planet.spr', 0, 0)

In the first line, you assign the room object type to your script variable giving the unique argument, the name that will be visible on the in-game interface. The second line defines the texture image sprite for the base background with the argument list roomvariable, linkname, spriteaddress, centerx, centery.

Ship placement 

Base.Ship (room1, 'ship', (-0.3, -0.3, 6), (0, 0.93, -0.34), (-1, 0, 0))

The above code defines the placement for the ship in room1, assuming room1 is the landing pad room or the repairs and upgrades room, where the player's ship should show. It has the form: Base.Ship (roomvariable, linkname, vectorP, vectorR, vectorQ)

where:

  • roomvariable - the room in which you place the button
  • linkname - arbitrary name to make your code readable
  • vectorP - position of the ship with (centerx, centery, scale) -- Note that scale is a Z coordinate in perspective, so you must adjust your X and Y accordingly as it gets farther away.
  • vectorR - ship up orientation with up-vector coordinates (x, y, z)
  • vectorQ - ship nose orientation with forward-vector coordinates (x, y, z)

Testimonial by chuck_starchaser

Adjusting these vectors (particularly the up and forward) manually, by trial and error, can be very time consuming and tedious. The sum of the squares of the x, y and z values in the up and forward vectors must add to one. In other words, the vectors should be "normalized", or of "unit-length". Also, the up and forward vectors should be normal (perpendicular) to one another. In arithmetic terms, their dot product should be zero. And what's the dot-product? The result of multiplying up.x times forward.x, adding to that the product of up.y times forward.y, and adding to that the product of up.z times forward.z. That should be zero if the two vectors are perpendicular. Yes; it's Hell; been there and survived. But there's an escape... maybe...

If you have a background artwork with a given perspective of the landing pad, say, you may want to load it into Blender as a background image. Set your view to orthogonal, with positive x to the right, and positive y up on the screen. Place a cube. Scale it so it's 2 x 2 x 2 size. Go to perspective, transparent mode (Numpad 5, Z in Blender). Set your view so that the cube extends over the screen, half visible, half beyond the screen borders. Now, load the mesh of a typical ship that you'd have land there. Do NOT change your view; but rotate the ship's mesh to get the perspective of it you want, over the picture. Now you can snap your cursor to the center of the ship (Shift-S, Cursor to selection, in Object mode) and read the cursor's position from the View Properties screen. That's NOT the values you want for the P vector, but save them for now. For the forward vector, in edit mode, select the nose vertex for the ship, snap cursor, write down the xyz. Subtract the xyz for the ship's center. Normalize it (i.e.: divide all three numbers by the square root of the sum of the squares. That's your vectorQ. For the UP vector, find any two vertices on the ship that are vertically aligned, get their coords, subtract, normalize.

VectorP will be a bit trickier: You need to measure the position of the center of the ship on-screen, placing a ruler on your monitor, careful not to scratch it. And you need to translate those measurements to VS screen coordinates, where the far left is -1 X, far right is +1 X, top is +1 Y, bottom is -1 Y. The two numbers you obtained are centerx and centery, but what should scale be? Frankly, I (chuck starchaser) don't know how scale works; I just adjusted it for PU by trial and error.

Hope this helps. The idea for this Blender method came to me in retrospect, today (May 23, 2008), and I haven't actually tested it. Be sure to edit this document to fix it as necessary, if you do make it work; or if you come up with a better method.


Button definition 

Base.Comp (room1, 'CargoComputer', 0.289063, -0.283854, 0.146484, 0.179688, 'Cargo Computer', 'Cargo')
Base.Link (room1, 'goto_exterior', 0.3, -0.3, 0.5, 0.3, 'Planet Exterior', room2)

The above code defines the button for the cargo computer and a link button to an exterior background image with the following convention: Base.Object (roomvariable, linkname, leftx, bottomy, width, height, displaytext, linkobject )

where:

  • roomvariable - the room in which you place the button
  • linkname - arbitrary name to make your code readable
  • leftx, bottomy - button left bottom corner coordinates; ranging from -1 on the left to 1 on the right, -1 on bottom 1 on the top
  • width, height - button size; full screen size is 2, half screen is 1.
  • displaytext - the text that will be shown in game
  • linkobject - the variable name of the object in your python script or a name predefined in the engine

In addition, for Base.Comp, the linkobject is used to determine the services available at that particular computer:

  • Cargo
  • Missions
  • News
  • Info
  • Upgrade
  • ShipDealer

Including and Testing

You'll need to create a sprite file referencing the image. See more information on how to do this in HowTo:Edit HUDs

Selection and Vetting

Some Thoughts

Once you have chosen a replacement candidate and have one or more proposals...

The Process

If you are not sure that your texture meets the basic requirements, then please open a forum topic posting your textures. Please verify the summary of requirements above.

If a texture that you have created meets the texture requirements, then:

  • Open a poll for a reasonable period of time (e.g. 2 weeks) and describe:
    • which texture(s) you'd like to replace
    • display your candidates
    • briefly describe the method of creation and tools used
    • If you'd like to replace more than one texture, describe how you would assign the favorites of the poll to the individual textures
  • After a set period of time
    • announce the winners
    • and call the poll closed
  • Then
    • Submit the textures to svn (in case you have commit rights attributed), or
    • through the forum ask a developer with write access to submit them (e.g. the maintainer of this page, pyramid).

Submission

AKA: Committing to SVN.


References

Software, Tools

For a comprehensive list of tools, please see:

See Also


Author: pyramid

Retrieved from "https://wiki.vega-strike.org/mediawiki/index.php?title=Development:Base_Backgrounds&oldid=15284"