GP Texture Editor Beta

tgibson

Resource contributor
Hi Don,

I have tested the horizontal part of the GP Texture Editor and I can't get past a certain point. I created a horizontal texture using your gp_PatternedLines_40F texture, turned 90 degrees to the right.

First a general comment. In every other program I've seen that handles texture bitmaps, the top is pixel 0 and the bottom is the largest pixel number. It seems to be the opposite here - the 0 pixel is at the bottom. This makes it hard to obtain the proper pixel numbers from a typical paint program - I have to subtract the height of the bitmap from all numbers I get from it. Starting at the top would be much easier.

1. Added this horizontal stripe texture to the Texture Editor. The entry in the Texture_Def file looks fine - it appears you have fixed the U vs V problem, and most of the button activation issue (see below).

It entered this into the Line_Def file:

Dotted Red | gp_PatternedLines_TRG | V=3 | 15 | 256

This looks fine, except for the 256. The same entry for the default 40F texture says:

Dashed - Short (Red) | gp_PatternedLines_40F | U=497 | 8 | 512

Note it says 512, the correct size of the bitmap. It appears that the Texture Editor is not picking up the correct dimension of the bitmap - it is still using the width of the bitmap (used for vertical stripes) instead of the height of the bitmap for these horizontal stripes.

When I added a GP line in ADE, went to the GP Editor, and assigned it to my TRG horizontal stripe copy, it mapped it correctly to the red dotted line. Nice! Then I went back to ADE.

However, when I then tried to edit the line, I got this error message:



When I clicked OK I got a blank GP Editor with nothing I could do, other than close it with Cancel.

I tried manually editing the 256 to 512, but it didn't fix this error. However, I assume it would cause a problem for any line entry with a start value larger than 256. :)

I then tried editing my line texture. I selected my texture from the drop down box in the Texture Editor, and chose the only line style I had created (Dotted Red) from that drop down box. Then for fun I entered the value 2 in the position box (remember I only have one line style). I got this box:



ADE then closed after asking if I wanted to save my airport if I had made changes to the ADE airport part of the file.

So it doesn't appear to test for the maximum allowed value for the position index.

Then I added another line style - Dotted Yellow. I had to double click the Dotted Yellow name I created in the drop down box to activate the Update Definition Files button (entering the name and data in the text boxes didn't do it), but it did activate. But then I had to enter my numbers again.... Perhaps the number entry boxes should not activate until the Update button activates?

However, after clicking the Update button it did add my line:

Dotted Yellow | gp_PatternedLines_TRG | V=407 | 15 | 256

Still adding it as a 256 pixel bitmap, of course, so I changed that manually to 512. It also changed my Dotted Red entry back to 256. Changed that one too. Otherwise it looks fine.

I did ask to place it in Position #2 in the listing, but it displayed as Position #1 in the drop down box. Huh? I looked at the Lines_Def file and found the answer - it did place it at position number 2 in the file, but in position #1 was an entry for the default 40F file, so my Dotted Yellow shows up as position #1 in the drop down box because it's the first entry *for my TRG copy*.

Here is the top of my Lines_Def file to illustrate:

Hold-Short | gp_PatternedLines_40F | U=3 | 50 | 512
Dotted Yellow | gp_PatternedLines_TRG | V=407 | 15 | 256
Dotted Red | gp_PatternedLines_TRG | V=3 | 15 | 256
Apron Limit | gp_PatternedLines_40F | U=17 | 22 | 512
Single (Yellow) | gp_PatternedLines_40F | U=17 | 8 | 512
...

The file is default below this point.

As you can see, the Editor placed my new Dotted Yellow entry into the second position of the main listing, but not #2 in the listing for my TRG file. So it ends up #1 in the drop down box. If I try to enter it as a number greater than 2, I get the error/crash above. So they are always being added as #1, essentially. While this will certainly be confusing, it's not fatal.

BTW, the Cancel button is a bit unnerving for closing the Texture Editor window - I worried that my changes might be lost. Perhaps Close would be a better label?

I then created a line and assigned it to my new Dotted Yellow line - worked well. Compiled the airport and my yellow dotted line appears in FS just fine. Back to ADE and then attempted to edit my line. I got the same error I posted first in this message.

I think that will be enough for now. :)

Hope this helps,
 

Attachments

tgibson

Resource contributor
Second report.

The Texture Definition section does not have the same problem with the invalid position number, but a slight problem none the less.

In my current Texture_Def file there are 24 entries. If I choose 26 or greater for the position number, I get a popup box saying this is an invalid entry. I click OK. Then the Update Definition Files button is grayed out and I have to click the Cancel button and start again. Sort of inconvenient. Perhaps it should offer to put it at the bottom of the list instead?

If I choose 25 as the number, all that happens is that the Update button grays out and I'm left questioning what happened.

Hope this helps,
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
ADE will catch unhandled exceptions coming from any part of the application. So it will catch those coming from the library. The log itself will contain the detail of which method or function was called but in this case it seems that you already know.
 

tgibson

Resource contributor
Hi again,

Thanks, Jon - I was impressed that ADE caught that.

When I get the invalid entry message after setting the Texture Definition position box greater than the maximum value, I cannot click the Cancel button - the invalid message just keeps popping up until I change it to a valid number. Annoying, but not fatal.

Hope this helps,
 

tgibson

Resource contributor
Hi,

OK, using 0.39.

The edit crash is indeed gone, but the return to the GP Editor for editing is still a problem for horizontal lines (not vertical lines, they work fine).

Here is the initial choice I made for a yellow dotted line - looks fine:



then when I return to the Editor for editing the line - it's hard to see, but there are two connected vertices in the middle of the dotted yellow line, that's it:



I assume from your description of the 0.39 release that the other problems in my previous threads are still there, so I didn't retest them.

Hope this helps,
 

Attachments

gadgets

Resource contributor
Tom, the exception was due to your specification for the line. You have a start point of 497 and a width of 8, which exceeds the dimension of the texture (512). I discovered this would happen when I inadvertently did something similar myself while troubleshooting the earlier issue.

I must admit, after I got the line to display properly with a horizontally-oriented texture, I didn't bother to attempt to re-edit is - as you have.

Should be simple to fix.

I assume from your last message that this is the only remaining (known) issue with horizontally-oriented textures.

Don
 

tgibson

Resource contributor
?? 497 plus 8 is 505, well within the 512 limit.

BTW, that line was *your* line for the default 40F texture (vertical lines):

Dashed - Short (Red) | gp_PatternedLines_40F | U=497 | 8 | 512

My lines are:

Dotted Yellow | gp_PatternedLines_TRG | V=407 | 15 | 256
Dotted Red | gp_PatternedLines_TRG | V=3 | 15 | 256

which I manually edited to 512.

Hope this helps,
 

gadgets

Resource contributor
Sorry, My arithmetic is a little "off" this morning - trying to digest all the posts since I went off-line yesterday.

The problem I highlighted did, in fact, exist and has been fixed. Obviously, you ran into something else which, apparently, is now OK.

What I was really trying to do was to have you confirm that, from your perspective, there were no longer any issues with the Texture Editor and that the processing of horizontally-oriented textures was Ok up to the second edit.

Don
 

tgibson

Resource contributor
The only problems I see so far are that:

1. When you specify a horizontal line definition, it places the width of the texture instead of the height of the texture into the Lines_Def file. While the width is appropriate for vertical lines, it is not so for horizontal lines.

2. When I select a position number higher than the number of line textures when re-editing a line style, I get the ADE crash.

3. When creating line styles, the Update Definition Files button will not activate unless I change Vertical To Horizontal or the reverse. No other entry activates it. I would think that entering a Line Style Name and Position Number should be sufficient, as long as the other two numbers (Start and Width/Height) are valid?

4. When inserting new line styles or editing existing ones, the position you specify in the Editor is not the position it ends up in in the listing for that specific texture, since it is really specifying the position of the line definition in the main Lines_Def file, which is not really useful. It needs to be the position within the listings for that specific texture. The program needs to search through the listing for line definitions using that specific texture and place the line definition into the proper location of that sub-list. Perhaps keeping the line texture definitions first sorted by texture name and then by line definition position would be helpful?

5. When adding texture definitions, if I choose a position number 3 or more greater than the last entry I get the warning message. This message keeps popping up until I edit the value - I cannot press the Cancel button to just close the window, I just get the popup again.

6. When adding texture definitions, if I choose a position number 2 higher than the last entry I get no warning message, only the Update Definition Files buttons greys out and I'm left wondering what happened.

7. The Cancel button is rather unnerving - it suggests I will lose my edits, even after pressing the Update Definition Files button. Perhaps Close would be a better label?

Hope this helps,
 
Last edited:

gadgets

Resource contributor
Tom, I agree with, and have fixed accordingly, all your points except the first.

I'm curious as to why you think current operation is wrong. The purpose of that field is to define the maximum U/V which, for horizontally-oriented textures on a texture sheet h=256/v-512 is 512.

Don
 

tgibson

Resource contributor
Thanks. Regarding #1, your manual states:

"Size of texture - the number of pixels along the side of the texture sheet for which offsets are specified."

For a horizontal line texture, the side that is important is the height of the image, not the width.

When your PatternedLines 40F texture is turned 90 degrees to the right (my PatternedLines TRG texture), it is 256 wide and 512 high. I thus should be able to specify start locations between 1 and 511. The 0.39 Editor is entering 256 in that last position, rather than the 512 I was expecting. I assumed that this would have bad consequences when I tried to specify a start location larger than 256.

If instead this number should *always* be the width of the texture instead, then it is working properly in 0.39.

I'll test this again with 0.40 and let you know. :)

Thanks again,
 

gadgets

Resource contributor
Tom, I discovered that error also yesterday. But, with all the confusion yesterday morning, I'm not sure the fix made 0.0.39. It is in 0.0.40 however.

Also, I misunderstood your comment. Upon re-reading it, what you were suggesting is true and that's what is implemented in 0.0.40.

Don
 

tgibson

Resource contributor
OK, now testing with 1.60.4886 and 0.40.

The "returning to edit" problem seems to be fixed, thanks!

Problems remaining:

1. If I add a texture of any sort, the Editor suggests sort of a random position number, which differs from texture to texture. For the default Texture_Def file I have seen numbers from 20 (correct) to 24. If a texture that presents with a number larger than the correct one is then added to the files using the Update Definition Files button, ADE crashes with the following message:



2. When I try to enter a Texture Definition position number 2 greater than the number of existing textures I get the ADE crash notice - same as I posted above. Any number higher than this as well. I assume this is exactly the same cause as #1, just a different way to get to it. In #1 the GP Texture Editor suggests it, in #2 I do. So there are two problems here.

3. My horizontal texture is still being entered as 256 (as discussed in my previous post - it is 512 tall), and when I then try to enter a line style with a Start value greater than that in the GP Texture Editor it is rejected by the Editor as greater than the maximum. I had to lower the value to below 256, as I expected. Too bad I am not able to use half of my texture. :) After manually editing the 256 to 512 in the Lines_Def file it works fine.

4. I added three line styles to my new TRG horizontal texture, and that worked fine. I added them as 1, 2, and 3 and they were added at the top of the Lines_Def file. I then switched to your 40F line texture, and moved the Dashed Red Short style to position #2. It was moved properly to spot #5 (my three TRG styles, then one 40F style, and then the Dashed Red Short style). But when I tried to move it back to the bottom of the file (position 14), it ended up in position 8 of the Lines_Def file (spot #5 of the 40F listing). Other line styles I try to move to position 14 also end up in position 8/5. If I try to move them to position 4, they end up in 6/3. To position 5, 6, 7, or 8, all end up in 7/4. To position 9, 10, 11, 12, 13, or 14, all end up in 8/5.

5. When I try to delete the last line style of a given texture (I was trying to delete line definition #3 of 3), I get this ADE crash:



The line style has been deleted from the Lines_Def file, though.

Hope this helps,
 

Attachments

tgibson

Resource contributor
I think you fixed the 256/512 problem the wrong way. Now even the vertical stripe textures are being entered as 256 rather than 512. Here is an excerpt of my file - I have moved the position of some of the default line styles and they are now listed as 256 instead of the proper 512. New texture's line styles are being entered incorrectly too:

Dotted Yellow | gp_PatternedLines_TRG | V=407 | 15 | 256
Dotted Red | gp_PatternedLines_TRG | V=3 | 15 | 512
Dotted White | gp_PatternedLines_TRG | V=57 | 15 | 256
Apron Limit | gp_PatternedLines_40F | U=17 | 22 | 512
Single (Yellow) | gp_PatternedLines_40F | U=17 | 8 | 512
Single (White) | gp_PatternedLines_40F | U=275 | 8 | 512
Dashed - Short (Red) | gp_PatternedLines_40F | U=497 | 8 | 256
Dashed - Short (Yellow) | gp_PatternedLines_40F | U=92 | 8 | 256
Hold-Short | gp_PatternedLines_40F | U=3 | 50 | 256
Dashed - Short (White) | gp_PatternedLines_40F | U=340 | 8 | 256

These should all be 512 - any that are 256 have been altered/entered by the GP Texture Editor to the wrong value. I had manually edited my Dotted Red line style previously to 512.

Hope this helps,
 
Last edited:

gadgets

Resource contributor
Tom, was the Horizontal checkbox actually checked when the textures were saved. ADE_GP has no way of knowing what's actully on the texturte sheet.

Don
 

tgibson

Resource contributor
I don't know. As you can see from my Lines_Def excerpt above, my horizontal TRG texture lines are set to V and your 40F lines are set to U, so I entered them correctly when I initially added them. And, it appears that when you load a line style, the Editor reads the U or V and sets the radio buttons accordingly? I didn't change anything after I reloaded the line style.

I just checked and the radio button switches from Horizontal to Vertical and visa versa when I load one or the other, so that seems to be working OK.

I just checked again when I was sure the button was set at Vertical for the 40F texture and Horizontal for the TRG texture, and the result is the same - I am getting 256 instead of the correct 512.

BTW, when you select a new Texture the Line Definition section could be reset to None and the rest grayed out. It now stays at the old settings, even though they are not valid for that new texture.

Hope this helps,
 

gadgets

Resource contributor
My apologizes once again, Sir. With that line configuration on the texture sheet, the final entry in the LinesDef file should be 512, irrespective of the orientation. For some reason, I had it in my head that it should change when going from horizontal to vertical orientation and vice versa.

It now works the way you said it should (i hope).

If I add a texture of any sort, the Editor suggests sort of a random position number, which differs from texture to texture. For the default Texture_Def file I have seen numbers from 20 (correct) to 24.
I was unable to reproduce this and can see nothing in the code. Please check again in the next release.

Most if not all the exceptions due to faulty indices should be gone in the next release.

Don
 

tgibson

Resource contributor
Hi,

No problem, it also took me a while to get my head around the orientation change required for vertical vs horizontal. I think you are being very brave in allowing horizontal lines - I would have limited it to vertical lines only. :)

I just tried it again with the 0.40 release and I found the problem with the inappropriate position numbers being offered. Here is my Texture_Def file:

gp_PatternedLines_TRG|40F|80F|False
gp_PatternedLines_40F|0F|40F|False
gp_ParkingDes|0|0|false
gp_Patterns|0|0|false
gp_LineBase|20F|20F|true
gp_Asphalt-dark|20F|20F|true
gp_Asphalt-light|20F|20F|false
gp_Asphalt-medium|20F|20F|true
gp_Concrete|20F|20F|true
gp_Dirt|20F|20F|false
gp_Gravel|20F|20F|false
gp_Red_20F|20F|20F|true
gp_White_20F|20F|20F|true
gp_Yellow_20F|20F|20F|true
gp_CrossHatch_Red|20F|20F|false
gp_CrossHatch_White|20F|20F|false
gp_CrossHatch_Yellow|20F|20F|false
gp_Signs_Red|0|0|false
gp_Signs_White|0|0|false
gp_Signs_Yellow|0|0|false
gp_CC_oakland|400F|100F|False

There are 21 entries, so the next one in the list should be 22.

I have 3 textures not yet added to the Texture_Def file. They are the three displayed at the bottom of the listing:



When I display the first of my three textures, it offers me the correct number:



This texture can be added successfully, but I did not do so here.

But if I display the second one, the Editor instead increments the the position number by one more (even though I have not added the texture above):



This will crash ADE if added.

When I display the third texture, the Editor increments the position number by yet one more:



So the inappropriate position number is based on its location in the list displayed in the first image above. The more new textures you have in the listing, the worse the number offered becomes. I can display the files in any order and the inappropriate number offered stays the same for each texture, because it only depends on its position in the Editor listing.

Hope this helps,
 
Last edited:

gadgets

Resource contributor
I think you are being very brave in allowing horizontal lines - I would have limited it to vertical lines only.
By the time I realized how much trouble it was going to be, I felt it would probably be as much work to remove it as to complete it. Basically, it's a matter of getting my head around a few things.

Re the "random number, the problem is that I'm using the nuimber of items in the combobox as the limit when I should be usingh the number of entries in the list instead. I'm going to fix that, re-release and call it a day.

Don
 
Top