Strata Nova

Started by iWasAdam, April 08, 2019, 07:52:20

Previous topic - Next topic

Steve Elliott

Quote
it has a much more sci-fi feel to it which I think is a good look to go for?

Yes, I like the way this looks.
Win11 64Gb 12th Gen Intel i9 12900K 3.2Ghz Nvidia RTX 3070Ti 8Gb
Win11 16Gb 12th Gen Intel i5 12450H 2Ghz Nvidia RTX 2050 8Gb
Win11  Pro 8Gb Celeron Intel UHD Graphics 600
Win10/Linux Mint 16Gb 4th Gen Intel i5 4570 3.2GHz, Nvidia GeForce GTX 1050 2Gb
macOS 32Gb Apple M2Max
pi5 8Gb
Spectrum Next 2Mb

iWasAdam

Good to know I'm sort on the right track now.

There are a lot of very odd things that need to be sorted. planets, movement and orbits is one, the ui is another...

Next will be basic ships having destination and source - the previous version just didn't work correctly and there seemed to be a lot of cpu use going on (not exactly sure where?). But this time I am approaching it with the past code in mind...

Derron

For ships I had a simple system:
TSpacecraft (base for TMissile and TShip) had a simple sourcePlanetID and targetShipID (missiles were not able to target missiles, so targetSpacecraftID could work too) and a targetPlanetID.

When updating a ship it called UpdateMovement() - which changed effective velocity based on the own position towards the target position.
This was needed to implement that way as objects in space tend to change their position.

To make it effective you need a fast "ID->object" retrieval aproach. I used Brucey's TIntMap (so no "string/object"->object map like in original BlitzMax but a optimized number->object map). With Monkey2 you might have a similar lookup table object.
If you are not afraid of possible circular references you could avoid loose coupling (id-lookups) and directly store the "target:TSpaceEntity" (planets, ships , ...) and just request its current (cached!) position in space.
Think this isn't that cpu costly then and should be the way to go.


What's a bit more time consuming? The pathfinding - especially with the avoidance of obstacles.
You could do the simple a-star-pathfinding and mark "grids" as occupied/blocked or not (so planets occupy grids). Grid states would need to get cached so that blocking/owner states do not lead to costly calculations. Means: a planet moves and refreshes its grid position - this informs the grid system and it sets the corresponding cell's ownership (so "flyby/harbor-approach" would be possible - compared to "avoidance").
This is better as it allows to also make the targetplanet "reachable".


bye
Ron

iWasAdam

interesting.

I'm definitely not using any of the Map functions - I don't know what it is, but I have always had the feeling there is something not right in the internals of it. I've certainly come across strange allocation issues in the past.

For the resources lists, etc - I have a very simple but completely bomb proof way of dealing with index entries that doesn't shift data around and combines the best of arrays with lists.

Here's the updated UI with details being shown:

Derron

@ Maps etc.:
If you iterate over a list/map/bag/... and inbetween remove one of the entries you are doing a "concurrent modification".
Assume you have an array:
Code (Blitzmax) Select

For local i:int = 0 until array.length
  processEntry( array[i] )
Next

Now the processing of the 10th element (i = 9) removes itself from the array somehow.
Eg. "Remove(me)" -> array = array[.. myID] + array[myID+1 ..]). This means that at "i = 9" now the old "i=10" is stored, at "i = 10" you will find the previously 11th element and so on - they shift -1.

The for loop is not knowing about the change. It now processes the 10th element after this 9th element (which removed itself). But this means it actually processes the element previously stored at the index=11. The index "10" (which is now stored at "9" because the old "9" was removed) is skipped in the whole update process.


In the example above this leads to "just" a skipped update - but now assume you somewhere start a process which identifies indexes for deletion. If you now do a "step by step" deletion (1st item, then 2nd of the delete-index, then 3rd.) you are actually deleting the wrong elements as they "shift" inbetween.

So for arrays this means you better create a new array containing all elements not being in the array containing the "to delete indices". Or you subtract a "deletedAmount" to the index access so it takes the shift into consideration.
For array the "new array" might be better as each "arr = arr[..index] + arr[index+1. .]" creates already new arrays (memory, cpu ...).


Hash maps, linked lists ... work differently for having elements linking other entries in the map together - so if removing them these links get updated and it should work too. Yet eg. in BlitzMax (NG) TMap and TList had issues with concurrent modification too.


bye
Ron

iWasAdam

Again interesting to see. but not a solution I would ever use in code as it 'data hides' the intention.

My preference is to go for some base container class with a kind variable.
if the kind = NULL then don't process

loop through all units and check if they are valid and then do something. That way you are 'checking' for known valid stuff and doing known things to the data.

TMaps / hash tables, etc do their best to hide what is being done - which in turn (for me) makes the code very difficult to read and work out what is going on.  :-[

I also feel that data is always reliant on other data and data references. The code gets very nasty and adding (hiding) stuff into the mix just makes it more complex.

Derron

Maps, lists, ... they are all some kind of "container" in which you throw stuff. Some behave like shelves (maps), some like stacking boxes (arrays) and some like bags (TList - sort order defines the "heaviest" which lands at the bottom).

I assume you use some kind of "pool" mechanism. You have a set of 1000 entities - if a ship is dead it changes entityType from ship to "none" and then this is an entity which can get reused.

Any usage of this ship either needs a lookup (from the "1000 entries array" - expensive) or you need to cache this lookup by providing a reference ("field target:TEntity = ship"). Now I assume your element having such a reference checks the containing entities for being not "none" each time - or to only process stuff if it is not "none" ?


@ hide away
I love this "hide away" in most cases as it allows to keep code "easy": container - add, remove, get. And you get that often for free, no need to write the code for it.
Performance wise there might be better options but especially for our "fire and forget" projects it's nice to save some time - and maybe avoid bugs (not that much apparant in "matured modules").
This is one of the reasons to have sprite classes, bitmap font classes ... you are not interested in the implementation. Just have "sprite.Draw(x,y)" and it works, do a "sprite.DrawArea(x,y,w,h)" and it handles it according to the sprites definition (stretch, tile, 9patch, ...). Same for lists, maps, arrays.

Yet your solution might have some benefits too - might depend on the project what outweights the other approach.




bye
Ron

iWasAdam

Sorting out some resolution independent scalable graphics:

iWasAdam

more UI and added rotations to planets:
Still no Game, but I am having fun watching planetary motions :)

Steve Elliott

lol having fun then, looks great.  The white symbols look a bit out of place, maybe a light green or blue/green colour instead?
Win11 64Gb 12th Gen Intel i9 12900K 3.2Ghz Nvidia RTX 3070Ti 8Gb
Win11 16Gb 12th Gen Intel i5 12450H 2Ghz Nvidia RTX 2050 8Gb
Win11  Pro 8Gb Celeron Intel UHD Graphics 600
Win10/Linux Mint 16Gb 4th Gen Intel i5 4570 3.2GHz, Nvidia GeForce GTX 1050 2Gb
macOS 32Gb Apple M2Max
pi5 8Gb
Spectrum Next 2Mb

iWasAdam

#55
Yep... a lot is still just placeholders, so colors, graphics - everything is likely to change in some way.

After throwing a hissy-fit and eating all the chocolate yesterday. I cracked a problem I was having:


It's not much to look at..., but it actually correctly depth sorting the planets as they rotate plus line widths are also being correctly scaled! I should add there is NO 3d being used. just some sin and cos and 2d graphics 8)

As was once sung:
It's a Sin!

iWasAdam

#56
if only I could turn a bitmap into a planet?  :(


iWasAdam


Derron

As I am a nitpicker: the light should be coming from the sun :p


bye
Ron

iWasAdam

and with a bit of color variation: