Spring RTS Engine

Whee... I only wish I had that much RAM. Meh, I just want one save state, if that's possible- even one level of Undo is better than, "gee, start this all over again".

suggest using savepoints (like quicksave in games, but rolling, that is keep 5-10 of them and allow easy loading.) will take more diskspace and would require manual saving before doing something to avoid interruptions... but maybe allow 'quicksave after every completed action' and let the os do the caching.

Yeah, that would do it. One of the major disadvantages of this tool is that you can't let anything go wrong at all. When placing stuff like roads, where you need pixel-perfect precision... well, people are going to screw up.

I don't mind losing the last 5 minutes of work, because I was too stupid to save a quick-save... but I lose the last hour or more? That's a "uninstall this program and never use it again" sort of error

feature request: disable rendering on opengl < 2 systems (intel...), but still allow loading, saving, import and export for compiler/decompiler functionality (especially that second, since there are command line compilers.)

Howdy!

So if this stuff is written in Java and uses Open GL, then it should pretty much run out of the box for me, even if I run Linux? At least in theory, correct?

Of course, the above assumes that my Java and Open GL environment both are in fantastic shape, which might not exactly be the case, but that should be possible for me to address if necessary. Hell, I got at least ONE java app running regularly (jEdit, even if it "just" is a IMHOkickass text editor) and yes, I got my OpenGL and hardware acceleration working nicely (yep, Spring runs as it should) so there is hope.

Maybe there is someone out there who already got this thing running on Linux?

Sounds cool in any case!

download and try it, there are linux shell startup scripts.

Quicksave&Quickload sounds ok.
If I compress the relevant arrays into memory, it might not eat too much ram, and could be still quite fast. (instead of writing to disk...)

@IllvilJa:
Currently linux with gtk lacks the GUI. if you use anything other than gtk, it should work normally. (But I'm working on it...)

@imbaczek:
I'll think about it. Currently I use the graphics card for doing the DXT1 compression/decompression, so it is not as easy as not creating the renderwindow... (Yes, I know the driver implementation is not perfect, but I did not feel like implementing it myself )

not sure if anyone else has mucked with the texture scripts.... a few questions, suggestions, requests...

firstly, this is good stuff! being able to set the tolerances for the slopes is key; with a bit of tweaking, i'm able to come out with pretty much exactly what i want... i'm going to share the scripts /textures i used after i release the maps i used them for as i go along, so there will be something from me shortly... should be a welcome addition to the program for novice mappers.

a request of something that seems that it may not be TOO hard to implement, but who knows...

i'd like to be able to run two scripts to texture my map. one to lay down a base layer of texture (like the default script that comes with the program) and another to add details, like the coloring of certain angles of slopes and flats...

i suppose what i'm asking for in terms of how i envisioned the process:
1) run a script to paint the whole map
2) run a secondary script with certain textures as "blank", so that i can create details only in specific places...

so okay... if i use the first script, i end up with something like this....


i'd be able to like to use a second script, to apply only to certain areas, like this....



an example of possible application... i'm working on a map right now with some mud slopes, it would be nice to add rock texture only to areas with certain steepnesses...

i can think of a few ways this would work, an easy-ish one might be to load a "blank" as a texture, and springmapedit would use an alpha-transparency channel to fill in an area rather than using an actual texture... i think for my purposes, even just to have the option to replace all "flat" textures in a script with something transparent to show the texture beneath would give the desired effect.

im not too sure of how the mechanics of implementing it would work, but i think this would raise the bar of SME generated textures from "pretty nice" to "omgsplooge."

also, i've noticed you mention a desire to include multiple climates... perhaps this idea of using multiple scripts ties into it... how about for defining climates, use something like a typemap to draw onto the map where you would like different texture scripts to be applied...

anyways keep up the excellent work sir!

So, I finally got around to taking a good deep look at this great tool. I really really liked the 1 click compiling, the feature placing, and the overall speed of the program. The texturing unit needs a bit of work, but I see you already have a lot of progress on that front.

My one biggest gripe still has to be camera movement, very clunky and unintuitive.

If middle click +drag could be rotate camera and right click +drab move camera on xy plane and scroll wheel go up/down, I think this would be so much more user friendly.

Thanks and keep up the good work!

hey,

ive just downloaded this and its being really slow even though it says im on like 60/100fps

it loads uop fine but then it goes really wierd

my system settings are :

windows vista
gfx card gforce 9800 GTX2 1 GIG
and a quad core processor

@KaiserJ:
If I got it right, you would just need more steps from flat to steep.
I think If I make it the same as for heightlevels, it should be what you need.
(Currently you have unlimited height-zones, but only 2 steepness zones.)

About "typemap for multiple scripts":

texturescripts/readme.txt wrote:Things to come (maybe...):

-multiple setups per map. areas defined by something similar to typemap.
(area1 uses this setup, area2 this, and area3 another)

@Beherith:
There will be multiple camera's to choose from. (Just like in spring...)
But first I have to clean up the keyboard/mousehandling code a bit.

@FrozenLegacy:
60-100 FPS is actually nowhere near where it should be on your system.
With my (slower than yours) setup,
CPU: X2 6000+
GFX: 8800GT 512MB
RAM: 2 GB
I get around 1500 FPS right after startup.

You could try this:
1. Update java (should be 1.6.x)
2. Update graphics card drivers
3. Did you force VSYNC in your drivers? If yes, disable it.
4. Changed anything inside config/settings.cfg? Revert to defaults...

Small news:
-Added singlethreaded fallback for Linux+GTK. GUI should show up now.
-Added Randomize_Heightmap, default key: C
-Added Set_Heightmap, default key: X (sets whole heightmap to given height == flat...)

Release maybe tonight.
Features which I want to implement before release:
-KaiserJ's multi flat->steep TexGen idea
-Quicksave&Quickload from RAM.

option to at least provide my own dds instead of generating on gpu please please please (if you do this, add a 'save minimap' option)

that would be a great addition to the scripts, being able to add more slope divisions.

in my explaination of what i envisioned... i wanted to add a rock texture to a certain angle of slope, regardless of the height on the map... i can do this now, right? i guess i'd just have to add more lines into each slope section... haha hopefully i can figure this out... but then again, maybe i can make something even cooler than what i was thinking with the way the scripts will be set up now hur hur

as far as multiple climates go i've considered just rendering two texturemaps using different scripts and photoshooping them together with a blend... doing it in-editor would get you much more accurate control IMO.

just a screenie of some of the scriptwork / experimenting i've been doing (and i've been doing some of the handpainting; was very impressed and inspired by the new S44 maps).... possibly going to use something like this script for the next map, nice and chilly :D not too much is changed between this script and the default, except for the tolerances and textures used. (ignore the tiles on the big flat areas! they will be hidden beneath some concrete ^^)

A quicksave / load would be super, thanks for taking the time on this, I'm really looking forward to less-sucky road implementation.

what about making roads into different layer ? you could edit roads, and then compile them together with the map... i suppose it doesnt support layers yet, so it would be great thing to add :)

Frost! Please also include better feature removal handling! ie all features within brush size are deleted rather than having to click on the exact origin center of the feature! This is desperately needed for me!

started blathering in my last post and end up muddying what i was trying to say

that's an image of another script thinger i've been workin on (6 texture levels this time) and i'd like to apply sort of a nice rocky texture to the mid levels of those cliffs... the problem is, i have so many horizontal texture layers mashed together to get that blending effect that when i change the steep texture for that height level, i get almost like sedimentary rock effect... just a really, really ugly one hurhur

anyways. its just a suggestion really, i'm sure i can come up with a good procedure even without a second slope texture, i just need to do more work ^^ (although it really would be extremely helpful)

I have java installed. i will reinstall and try it.

New Release: r616

Changes:
-updated windows startscripts (works now without java\bin in PATH)
-Allow single threaded GUI fallback. (GUI on Linux+GTK)
-added randomize heightmap. Default Key: C
-added flatten heightmap. Default Key: X
-fixed NPE if SME was closed before logo-dialog.
-added startupscripts for 1536 MB max RAM usage
-added Quicksave + Quickload. Default Keys: F8 and F12
(with optional compression)
-remove all Features below brush, instead of just closest one.
-made feature removing draggable

Notes:
Quicksave and quickload took me quite some time, mainly speed optimizations.
Without compression it doubles the needed amount of RAM (only if used).
With compression it "only" uses about an extra 50% of RAM.
Downside is: Compression takes quite some time. It is nearly as slow as writing to disk. Compression of quicksaves may be toggled on/off.
Maybe compression+writing to disk, or just writing to disk would be a better solution.
I need more time for experiments...

Currently I would suggest to only use uncompressed quicksaves.
If one succeeds without crashing (out of mem...), all will succeed.

@imbaczek:
Save/load minimap will be added, as my generated ones do not look very good. (Currently it is just the scaled down texturemap)
Specifying an external dds could indeed work, as I just would have to copy the data, without "understanding" it.
I googled for "ati driver texture compression mipmap" and found 2 interesting sites:
http://3dnature.com/ati.html
http://ogre3d.org/forums/viewtopic.php?f=4&t=47594

@KaiserJ:
Nice TexGen setup there :)
Unfortunately quicksave took me too much time, so extended TexGen will have to wait till next release.
(Maybe TexGen is even multithreaded in the next version )

@Linux users:
Please report if the GUI is showing up now.

Frostregen wrote: @Linux users:
Please report if the GUI is showing up now.

still no GUI

OpenGL version: 2.1.2 NVIDIA 177.82 -> (ok)
FeatureManager: added Feature: cluster1_dead
FeatureManager: added Feature: rock1
FeatureManager: added Feature: cluster1
FeatureManager: added Feature: geovent
FeatureManager: added Feature: corecom1
Exception in thread "Thread-3" org.eclipse.swt.SWTError: Not implemented [multiple displays]
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Display.checkDisplay(Unknown Source)
at org.eclipse.swt.widgets.Display.create(Unknown Source)
at org.eclipse.swt.graphics.Device.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at frontend.gui.SpringMapEditDialog$1.run(SpringMapEditDialog.java:97)
at java.lang.Thread.run(Thread.java:619)
Exception in thread "Thread-4" org.eclipse.swt.SWTError: Not implemented [multiple displays]
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Display.checkDisplay(Unknown Source)
at org.eclipse.swt.widgets.Display.create(Unknown Source)
at org.eclipse.swt.graphics.Device.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at frontend.gui.SpringMapEditDialog$2.run(SpringMapEditDialog.java:140)
at java.lang.Thread.run(Thread.java:619)