DrKevDog

World Editor-3P-4tfx

40 posts in this topic

World Editor-4tfx will include a number of sub-editors, including the terrain editor 3P-4tfx. 3P-4tfx is a new, workable, functioning terrain editor for editing EF2K, TAW, ADF 22 ADF and SeaWorld/Arcade. 3P-4tfx is a very powerful tool for easily and quickly modifying, editing, or even recreating the terrain environments in tfx, by simply painting with a brush. It is designed to meet the development needs from beginner level to professional level.

3P-4tfx stands for Pixel-Pointers-Painting program for tfx.

The more familiar you are with tfx terrain construction, the more powerful the tool.

In its most simplistic description, 3P-4tfx is a method for simply painting images on a bitmap template which can be easily and quickly converted to a tfx world environment (env) file. The game engine then does all the work of building the terrain world for you.

3P-4tfx employees the powerful engine of the raster graphics image editor: Gimp, but can be modified to any standard graphics image editor.

The working prototype is completed and here's a basic look at how it works:

 

Consider the very first image Krycztij posted in the Terrain Format Thread:

Pic1.jpg

Let’s consider the simplest case, which would be the clds1000.env image

If we zoom in to the image, we would see that each pixel has a uniquely identifying code; however, it is not easily detectable due to the limited 16bit base.

In 3P-4tfx, we have enhanced that feature and expanded the variables.

This is the 3P-Clouds-Template file:

Pic2.jpg

This is the image Zoom:

Pic3.jpg

Notice that each pixel unit is easily distinguishable:

I have encoded this feature into a format Gimp can interpret and process. When the Template is loaded and the user clicks on a pixel, Gimp reads the template and displays that corresponding tiles SSD name, its coordinates on the terrain map, the number of times it occurs on the map, the pointer value, etc..

capture_004_27052016_102250.jpg

Similarly for TAW and the redsea map:
Pic4.jpg

Essentially everything one needs to know to edit the terrain EF2k, F22ADF, TAW or SeaWorld/Arcade. Changing or even recreating the cloud or terrain world environments in tfx, has never been so easy.

It’s a virtual Painters paradise!

 

Share this post


Link to post
Share on other sites

Awesome :o I'd love to implement the capabilities of hot-swapping terrain files in TFXplorer (e.g. for real-time preview of what you're drawing) if I just had time … maybe some time in the next months.

Share this post


Link to post
Share on other sites

What I am looking to ultimately achieve is a World Editor with a Terrain Editor, Texture/Materials Editor, Particle Editor and Shape/Object Editor and an Infrastructure Editor and it should evolve along with TFXplorer. The Terrain Editor prototype gives me motivation and a lot of ideas. Last night I dug out mikews old Terrain Viewer from years ago and it makes me wonder if there is some way the two could be integrated and developed into a formal Gimp (Python based) plugin. Whenever you get the time, let me know and I'll get a bundle of what I have completed over to you.

Share this post


Link to post
Share on other sites

mikew had a terrain viewer? I must have missed that one. Or did you just blow the secret? ;) 

Do you need anything concerning ILBM bitmaps? Last time I checked, Gimp didn't support them, so I decided to write my own stuff for that. Then I noticed, there's hundreds of flavors of ILBM out there, and I tried to make them all compatible. Then it was three weeks later and three in the morning and I was thinking, wow, that escalated quickly. Anyway, I have some C++ code if you have any trouble loading those bitmaps.

Share this post


Link to post
Share on other sites

Wow, that was about 2008. I made a crude tile picker in VB5
mr1.jpg

...then render it and the 8 surrounding tiles in a Direct3d7 (or 8) window, again with VB5 code.
mr3.jpg

 

...at least if you didn't pick an 'awkward' tile.

Anyway, I totally agree with you DKD. I suppose making small specific tools first is the way to go, but in which language?
Python is not much fun for GUI work though.

A couple of months ago, I was looking at AC3d with a plugin as a 3 file editor, but enthusiasm sort of fizzled out.

Share this post


Link to post
Share on other sites

I'm using Windows bitmap images for the Templates in Gimp, I started with .raws in Irfanview but Gimp has so much more power, however, it only has a .raw plugin for exports not imports. I think that code for ILBM's would be very useful for me as I'm still working with the TAW ILBM maps to see if they can be of help in the future.

It seems like we follow TFXplorer for code then. My understanding is that there is a lot of Python support for Gimp plugins though.

For what I have now, the images aren't very user friendly and that's when I remembered the Terrain Viewer, using those images would be perfect.

Share this post


Link to post
Share on other sites

I think it would be useful for you both to see what this is and how it works so I emailed you the Redsea Template files. The readme contains the instructions but let me know if you have any questions

Share this post


Link to post
Share on other sites

It's a good idea to use a pre-existing tool for our purposes, but I'm not sure that an image editor like Gimp is suitable. Maybe a plugin can change its entire 'personality' though.

I think we need to be clear about what we want to achieve, and how to go about it. For a world level tool, I suppose we need to work with the .env,.lst and .asc files as a minimum.
We then need some way of picking/replacing/displaying the .ssd files making up the map.
The 3view dll can already be used to display individual ssd files, so that's what we'd use for any 3d rendering.

 

Share this post


Link to post
Share on other sites

I am very familiar with Gimp and it works well with the prototype to achieve the basic result, however, I am certainly open to using other tools we have available. The prototype does, in itself encompass the .env,.lst and .asc., keeping in mind that the .asc only functions to provide the # SSD files. The Template is a conversion of the .env and the palette houses the .lst. I can sense you have some ideas, perhaps with the Terrain Viewer and/or 3View in mind, and that is where we ultimately want to go.

Share this post


Link to post
Share on other sites

If you've got Gimp to treat the palette as some sort of ssd selector in a meaningful way, then that's ingenious. :D

I have plenty of ideas, but turning them into reality is another matter...
The key, for me at least, is being able to 'get going' with VB, wxPython or whatever so that programming becomes a pleasure.again.

Share this post


Link to post
Share on other sites

Yes, and the special file format (.gpl) which GIMP uses to store its palettes is a perfect platform and match for the
format tfx uses for its world environments implementation. Once I figured out how to incorporate the
unique functional significance of each terrain tiles index value into a Gimp readable pallette value, it became clear just how well the two processes match and was relatively easy to convert them. Also, the .gpl is an ASCII file so they aren't difficult to work with. One of the fun things about this project is that an editor, such as P3-4tfx, gives graphic immediate-gratification results so the 'pleasure-quotient' is fairly high :D

Share this post


Link to post
Share on other sites
On 5/28/2016 at 7:36 PM, mikew said:

Python is not much fun for GUI work though.

On a side note: Yesterday at work, I finally figured out how the scroll wheel can be used in a Win32 dialog. Took me less than four months :) I bet Python is not that bad.

Share this post


Link to post
Share on other sites
On 5/28/2016 at 8:46 PM, DrKevDog said:

I think that code for ILBM's would be very useful for me as I'm still working with the TAW ILBM maps to see if they can be of help in the future.

Here's my stuff: https://app.box.com/s/gkfbbopu7b0ywdewtkdixdx33q1lrs33

The ILBM loader is serious business; it supports many flavours (more than I found other libraries to do). You can even display the Deluxe Paint thumbnails in EF2000's files.

// This implementation supports:
//  • Containers:
//    – ILBM (Interlaced Bitmap)
//    – PBM (Planar Bitmap)
//    – ACBM (Amiga Continuous Bitmap)
//  • Color depths:
//    – 1–8-bit indexed
//    – 8/24/32-bit grayscale/RGB/RGBC (“deep”)
//    – 5/6-bit “Hold-and-Modify” (“HAM6”)
//    – 7/8-bit “Hold-and-Modify” (“HAM8”)
//    – 6-bit “Extra Half-Brite”
//    – 5/6-bit “Sliced Hold-and-Modify” (“SHAM”)
//    – 5/6-bit “NewTek Dynamic Hold-and-Modify” (“DHAM”)
//    – 4-bit “NewTek Dynamic HiRes”
//  • bit masks & color keys
//  • Deluxe Paint thumbnails (“TINY” chunks)
//  • annotations, comments, author & copyright information

The image viewer is very bad scratch code (you can't even scroll or zoom the image), but it does the trick for now (ILBMs never come in large dimensions).

For further information, see the readme and source codes.

:icon_salute3:

Share this post


Link to post
Share on other sites
6 hours ago, Krycztij said:

On a side note: Yesterday at work, I finally figured out how the scroll wheel can be used in a Win32 dialog. Took me less than four months :) I bet Python is not that bad.

Well done! The Win32 API just keeps on giving... :)

I suspect a bit of mission creep with that ILBM loader. Great stuff though!
When will it be able to create ILBM files? Sort of joking, but I was wondering if it would be useful to generate moving map LBM files as part of DKD's hypothetical world editor.

 

Share this post


Link to post
Share on other sites

Writing is much easier than reading, because EF2000's/TAW's ILBMs are in the most simple format and have fixed dimensions.

I don't see any further use cases (i.e. no reason to have that in my toolbox), so I'll leave that to you :) 

Share this post


Link to post
Share on other sites

Here's a new version of the ILBM viewer: https://app.box.com/s/vcrfar1prhxdqi1c2hn5xmth730xjvha

Major UI overhaul, so I hope it's much more useful for digging into DID's files.

  • added ability to zoom
  • image can be copied
  • fixed loading thumbnails from ILBMs where one side is more than 32× as long as the other

No time for packing the source code yet, but there's not much change in the ILBM code anyway (mostly UI stuff).

Btw, the 32-bit version runs on Windows XP if you install the Visual C++ 2015 Redistributable.

2016-06-07 Windows XP - Copy.png

 

Share this post


Link to post
Share on other sites

That is nice!  I am working on the redse_.lbm / redse_.map programs. What I need right now is a mathematical formula to describe how the index relates to the SSD terrain index (redsea.env). If anyone here knows how the redse_.lbm bitmaps are organized, please let me know.

Color-coding the redse_.map pointers and using mikews tawmmap python tool, I can see a definitive pattern in how the pointers map the images:

BigMap-pattern.jpg

When I compare the mmap pointers to the redsea.env pointer values I get a disconnect:

Arc-MMap-Pointers.jpg

There is also the issue of the randomization files, the mmap doesn't appear to use any randomization's, so the .env and .map's seem to be separate systems?

Share this post


Link to post
Share on other sites

Yes, it's still a mystery regarding how each 16x16 bitmap from redse_.lbm is related to its corresponding ssd tile.

The significant difference between redse_.map and redsea.env is that the raster goes in a different direction. IIRC, it starts from the lower left in redsea.env with the next entry for the tile above. For rede_.map, the origin is the top left, with subsequent entries moving to the right.
That's all from memory though...

Share this post


Link to post
Share on other sites
11 hours ago, DrKevDog said:

What I need right now is a mathematical formula to describe how the index relates to the SSD terrain index (redsea.env).

You mean: Given the SSD index, how to find the redse_.map value? That's an interesting problem for me, too — after all, there was no need for redse_.map at all if we could just compute values from the .env file.

Didn't you use Seaworld's .env file some time ago to compute a moving map from it?

Share this post


Link to post
Share on other sites

I believe the correct formula would be a function of the raster relationships, however, the problem is that the pointer domains are not equal. For example; .map contains pointers to descrop_x, no such pointer exists in redsea.env.

I did use Seaworld's .env file to compute a moving map for it. The image shape was correct and the pointer-UV placements did jibe. Unfortunately, back then, I assumed the noname605 ILBM was the correct image file for Seaworld...I now know that I was wrong.

It now appears as if the MMap is completely independent of the terrain .env / asc / .lst sytem, I hope I'm wrong.

I'm left with manually cross referencing the .map pointers with the .env pointers. There has got to be a better way... :rolleyes:

Share this post


Link to post
Share on other sites
51 minutes ago, DrKevDog said:

IFor example; .map contains pointers to descrop_x, no such pointer exists in redsea.env.

I thought the redse_.map just held pointers to the 398 or so bitmaps in redse_.lbm.

For our hypothetical world editor,we would generate the moving map files at the same time as the .env/.lst/.asc, but we need some way of tying up an ssd file with its moving map.equivalent. I have no idea how DID did that, or why two separate systems are used. EF2000 didn't have the same moving map system, so maybe they just imported the solution from another project.

Share this post


Link to post
Share on other sites

Clarification: redse_.map contains a pointer to the bitmap image which correlates to descrop_x.ssd. Redsea.envv has no pointer to descrop_x.ssd and yet the default moving map displays the bitmap image of descrop_x, when the user is over the corresponding UV coordinates, because that pointer exists in the redse_.map. I'm not sure what you mean by "...398 or so bitmaps", there are 814 bitmap images in redse_.lbm,  [32e(h)]?

"...but we need some way of tying up an ssd file with its moving map.equivalent."  Exactly!

 

Here is a modified tawbig, map where I have tagged each bitmap tile with its correct pointer value.

1 word pointers (consider endianess) and the 1st byte (least significant)  is represented the value on the map.

2nd byte is represented by color:

00 = red

01 = green

02 = orange

03 = white

http://www61.zippyshare.com/v/tj3yx66r/file.html

The patterns are suggestive.

 

Share this post


Link to post
Share on other sites

814 pointers in the index for the moving map, 999 pointers in the index for the red sea SSD's. 320,000 pointers for 160,000 points. The initial compilation generated 3335 pages :whoa: in the list document. Parsing for only the unique bindings generated a total of 2542 index pairings. This was sufficient and the current independent moving map template is now functional in the prototype editor  :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now