Jump to content

World Editor-3P-4tfx


Recommended Posts

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:


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:


This is the image Zoom:


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..


Similarly for TAW and the redsea map:

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!


Link to comment
Share on other sites

  • Replies 84
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
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.

Link to comment
Share on other sites

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

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


...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.

Link to comment
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.

Link to comment
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.


Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment
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.


Link to comment
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.


Link to comment
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


Link to comment
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:


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


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?

Link to comment
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...

Link to comment
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?

Link to comment
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:

Link to comment
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.

Link to comment
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


The patterns are suggestive.


Link to comment
Share on other sites

  • 3 weeks later...

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  :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...