Tool: TrackEditor (Former Problem with WM_MouseWheel)

[Michael Hartlef]

Hi folks,

I have a problem with %WM_MouseWheel. As long as I don't click inside the listbox to select a new tile item, you can zoom in and out with the mouse wheel. If you hold the left control key, the map rotates. Now comes the werid part. Select a new tile item in the list box.

Now you can not zoom in and out anymore, BUT... you can still rotate!

Any hint is appreciated.

Michael

[Petr Schreiber]

Hi Mike,

I think it is problem of control focus.
Try to set focus back to graphic canvas after listbox selection, like:


CASE %List01
SELECT CASE HIWRD( CBWPARAM )
CASE %LBN_SELCHANGE
LISTBOX GET TEXT CBHNDL, %List01 TO partStr
partNo = FindModelID( partStr )
STATUSBAR_SETTEXT hDlg, %ID_STATUSBAR, "Part: " & partStr & " No:" & partno, 4

control set focus hDlg, %gCanvas

CASE %LBN_DBLCLK
LISTBOX GET TEXT CBHNDL, %List01 TO tmpStr
LISTBOX GET SELECTED CBHNDL, %List01 TO partNo
STATUSBAR_SETTEXT hDlg, %ID_STATUSBAR, "Part: " & partStr, 4

control set focus hDlg, %gCanvas
END SELECT


It helped on my PC.


Petr

P.S. The editor is very nice!

[ErosOlmi]

This is my track.
Michael, karma point on the way ... ;D

[Petr Schreiber]

Huuuu huuu uuuuu uuuu,

Eros, is there any chance you took a screenshot on PC with Microsoft software implementation of OpenGL?
I do not get that much jagged edges on my box. I remember the odd look was the same on my grandpa PC, who had Radeon, but no drivers, so it used Microsoft software rendering and it had the same amount of odd ZBuffering look.


Petr

[ErosOlmi]

Eros, is there any chance you took a screenshot on PC with Microsoft software implementation of OpenGL?
I do not get that much jagged edges on my box.

I created that track on my wife pc that has an Intel Q35 Express card. But the PC is super fast Core 2 2.66 GH 2Gb ram.

At home I have 2 desktop (one for my son has nVidia card, one for my wife has Intel card) 2 laptops (both mine with ATI cards) and one tablet PC (again mine with ATI, I use it when I'm in mine thoughts room: the bathroom ;D).

[Petr Schreiber]

Thanks Eros,

I know I am terrible, but if your wife will pass you her PC ( not necessarily now, just anywhere in future! ), could you run the OpenGL "analyser" from here (http://community.thinbasic.com/index.php?topic=668.0)?

I think that chipset has "Intel GMA 3100", last beast from Intel. Should be very good, but I heard some horror stories as well, some say it needs to wait for mature drivers ... anyway the Z-fight amount surprised even me.


Petr

P.S. Mike, I am sorry to hijack the thread but I was surprised.

[ErosOlmi]

Here is the solution for Michael problem (I hope):



CASE %WM_MOUSEWHEEL
mouseDelta = HIINT( CBwPARAM )
IF mouseDelta > 0 THEN


Reference: http://msdn.microsoft.com/en-us/library/ms645617(VS.85).aspx

[ErosOlmi]

My wife's PC report:
_________________________________________________
Vendor: INTEL
Renderer: INTEL BEAR LAKE B
OpenGL: 1.4.0 - BUILD 7.14.10.4837
Extensions( 46 ):
GL_ARB_DEPTH_TEXTURE
GL_ARB_FRAGMENT_PROGRAM
GL_ARB_MULTITEXTURE
GL_ARB_POINT_PARAMETERS
GL_ARB_SHADOW
GL_ARB_TEXTURE_BORDER_CLAMP
GL_ARB_TEXTURE_COMPRESSION
GL_ARB_TEXTURE_CUBE_MAP
GL_ARB_TEXTURE_ENV_ADD
GL_ARB_TEXTURE_ENV_COMBINE
GL_ARB_TEXTURE_ENV_DOT3
GL_ARB_TEXTURE_ENV_CROSSBAR
GL_ARB_TRANSPOSE_MATRIX
GL_ARB_VERTEX_BUFFER_OBJECT
GL_ARB_VERTEX_PROGRAM
GL_ARB_WINDOW_POS
GL_EXT_ABGR
GL_EXT_BGRA
GL_EXT_BLEND_COLOR
GL_EXT_BLEND_FUNC_SEPARATE
GL_EXT_BLEND_MINMAX
GL_EXT_BLEND_SUBTRACT
GL_EXT_CLIP_VOLUME_HINT
GL_EXT_COMPILED_VERTEX_ARRAY
GL_EXT_CULL_VERTEX
GL_EXT_DRAW_RANGE_ELEMENTS
GL_EXT_FOG_COORD
GL_EXT_MULTI_DRAW_ARRAYS
GL_EXT_PACKED_PIXELS
GL_EXT_RESCALE_NORMAL
GL_EXT_SECONDARY_COLOR
GL_EXT_SEPARATE_SPECULAR_COLOR
GL_EXT_SHADOW_FUNCS
GL_EXT_STENCIL_TWO_SIDE
GL_EXT_STENCIL_WRAP
GL_EXT_TEXTURE_COMPRESSION_S3TC
GL_EXT_TEXTURE_ENV_ADD
GL_EXT_TEXTURE_ENV_COMBINE
GL_EXT_TEXTURE_FILTER_ANISOTROPIC
GL_EXT_TEXTURE3D
GL_3DFX_TEXTURE_COMPRESSION_FXT1
GL_IBM_TEXTURE_MIRRORED_REPEAT
GL_NV_BLEND_SQUARE
GL_NV_TEXGEN_REFLECTION
GL_SGIS_GENERATE_MIPMAP
GL_WIN_SWAP_HINT

[Petr Schreiber]

Thank you Eros,

and apologies to your wife :-[

I use the following in TBGL, looks odd, works good :):


CASE %WM_MOUSEWHEEL

tbgl_MouseWheelDelta = HIWRD( wParam)

IF tbgl_MouseWheelDelta/120 = tbgl_MouseWheelDelta\120 THEN
tbgl_MouseWheelDelta = 1
ELSE
tbgl_MouseWheelDelta = -1
END IF



Petr

[ErosOlmi]

Microsoft documentation talks about positive and negative values so it cannot be an unsigned number but signed one.
So WORD is not the solution but INTEGER yes.

[ErosOlmi]

On my ATI card it is much better

[Petr Schreiber]

That is true,

Your is better, I don't know why I did it in such an esoteric manner :)
I probably saw HIWORD( wParam ) and missed cast ot (short) in Win32 docs.


Petr

P.S. Thanks for ATi test

[ErosOlmi]

Well, thank you to you for the TBGL canvas. It is so capable. I think you could create a custom control and make a lot of $$$$ ;)

Anyhow I've added the following equates in next thinBasic UI module so it will simpler to manage mouse wheel and key pressing mask:
%MK_LBUTTON
%MK_RBUTTON
%MK_SHIFT
%MK_CONTROL
%MK_MBUTTON
%MK_XBUTTON1
%MK_XBUTTON2

Ciao
Eros

[Petr Schreiber]

I am not tradesman,

which makes me wonder how I will survive in not so distant future :D

Thanks for those new equates, looks good.
What is difference between MK_ and VK_ ?


Petr

[ErosOlmi]

I am not tradesman,
which makes me wonder how I will survive in not so distant future :D

Important is to be honest man. I'm sure the rest can only come automatically.




What is difference between MK_ and VK_ ?

I really do not know. Equates are from Microsoft docs at http://msdn.microsoft.com/en-us/library/ms645617(VS.85).aspx
I suppose VK stands for Virtual Key while MK stands for Mask Key because the lower INTEGER is used as a mask in %WM_MOUSEWHEEL notification and more MK... flags can be on at the same time.

Ciao
Eros

[ErosOlmi]

Michael, a little suggestion for track editor:

please do not use confirmation when [X] click but just check if track file has changed.
If yes ask to save: yes, no, cancel.
Yes and no will just save or not save and than exit.
Cancel will just undo [X] closing.

Personally I do like continuous confirmations. They must be used when really needed not for every steps.

Thanks
Eros

Of course: great work. I've already added a karma point.

[ErosOlmi]

Post moved to CM Contest 2009.
It was a pity to downgrade this post to a simple UI problem :D
It is a so good and nice track editor.

[Michael Hartlef]

Thanksguys for the flowers. I just didn't wanna put it there for now as it isn't fully ready. But I think it can be usefull. the next step is to save the modelname-ID relationship so when models get added or removed, it won't destroy the saved tracks.

[Michael Hartlef]

Ok, here comes the next problem. Start the editor and press R or L, you can rotate in 90 degrees steps. Now select a new track part and now you can only rotate in 180 degrees. ??? At least it looks like, because I think the keypress is detected twies.

How can I solve this?

Btw. former saved tracks are not compatible anymore. Next version will support a chunk based fileformat so new additions to the fileformat won't break old files.

[ErosOlmi]

Seems only the first time TBGL_GetWindowKeyOnce really determine the "once" while after a new track part is selected TBGL_GetWindowKeyOnce works like TBGL_GetWindowKeyState ???

I'm checking if something in UI module can interfere in some way ..

[Michael Clease]

you are using TBGL_GETWINDOWKEYONCE but you never reset it. ;)

I moved the GETASYNCKEYSTATE( - 1 ) out of that routine and added TBGL_ResetKeyState()

add them both in the tbmain


appstate = %stEdit

TBGL_ResetKeyState()
GETASYNCKEYSTATE( - 1 )

DIALOG SHOW MODAL hDlg, CALL DlgProc

but I dont think that is the best place for them. But I have to go out so I will let you play.

[ErosOlmi]

Problem is not TBGL_GetWindowKeyOnce. It is working fine.
Problem is that successive turning is fired by


CASE %ID_TurnRight, %btn_right
RotateTileRight( )
CASE %ID_TurnLeft, %btn_left
RotateTileLeft( )

in %WM_COMMAND events

Comment out above line events and R and L keys will work fine.

Still checking ...

[ErosOlmi]

Ok, found the problem.

Remove "&" from button text

CONTROL ADD BUTTON, hDlg, %btn_left, "&Left", 520, 5, 45, 15
CONTROL ADD BUTTON, hDlg, %btn_Right, "&Right", 575, 5, 45, 15

and just leave as:

CONTROL ADD BUTTON, hDlg, %btn_left, "Left", 520, 5, 45, 15
CONTROL ADD BUTTON, hDlg, %btn_Right, "Right", 575, 5, 45, 15

otherwise standard windows behave will fire another left or right command.

Eros

[Petr Schreiber]

EDIT: Eros was faster again :)

Hi,

the problem is buttons have &R and &L, that means after change of focus from cavas to dialog / listbox ... the R and L is captured by Windows and then by TBGL function.

Solution is to get rid of &Left, &Right in button name.

Other important thing is to filter messages properly, so use CBCTLMSG test:


CASE %ID_TurnLeft, %btn_left
if CBCTLMSG = %BN_CLICKED THEN
RotateTileLeft()
END IF


I attach working example for you.


Petr

P.S. Mike, this editor rocks! Very intuitive :)

[Petr Schreiber]

Mike,

we discussed this via PM - ability to show tile preview.
I did it using viewport approach, all new code is in Render_Track.


Petr

[ErosOlmi]

I agree, this editor rocks !

And because it already rocks, I would change the following (personal opinion):

track files from binary to text structured. In this way other users can create it easily following file directive. A sort of text file like Petr and Simone used for (respectively) 3D Labyrinth levels and Arkanoid levels.
when trackedit open, it nicely open the last edit file. But if changed it ask again the same of the file. It should instead save under current file name
when closing with [X] and file is changed, ask if to save with Yes, No but also Cancel button.Cancel will just not save and not exit. It cancel the event
have the option to move the camera to be able to see part of the track that goes off screen when zooming. For example when mouse reach the edge of the TBGL canvas (maybe last 5/10 pixels, just move camera left/right/top/bottom
possibility to modify inclination the camera


For today it can be enough ;D

Ciao
Eros

[ErosOlmi]

Tile preview :o :o :o :o OMG
We have really a great program here !!

Thanks a lot guy. I started to smile this morning and still not able to stop. My wife told me I'm a little crazy kid. I start to think she will call neurological staff today but fortunately I will be out for family stuff a while today afternoon so I think I will distract my mind from this.

[ErosOlmi]

Petr,

found a situation in your version that GPF the script.
Press inside the tile listbox where no element is present (white area). Here it GPF.

Eros

[Petr Schreiber]

Ooops,

I hope it not made you stop smiling, to make me sure I post correction here :)

Will help Mike with the other suggestions, just have to change from "coder" to "cook" for now :)


Petr

[ErosOlmi]

NOW PERFECT !

[Michael Hartlef]

Hi folks,

thanks for finding that simple solution. Sometimes you don't see the obvious.

Eros, I would have went the text file way to save stuff but the bug with UBOUND was a showstopper for me and the way I was going to parse the files. So I went the binary file way.

What real advantage do you see with a text file. Edit it by hand?


In this way other users can create it easily following file directive

??? Can you explain that in other words?

Petr, thanks for your modifications. I'll fire up winMerge and see what fits into my code.

[Michael Hartlef]

Ok, I made the preview optional. Eros, can't confirm the GPF here. Runs just fine.

[ErosOlmi]

Ok, I made the preview optional. Eros, can't confirm the GPF here. Runs just fine.

Maybe you missed one post. Petr already fixed it :D


Regarding text files for tracks, I know I stress, but it is something I've always loved since I started in IT world.
Test files are easy to manage, easy to implement and understand, easy to maintain and to be used by other programs.

In particular structured text files like INI or XML are very useful because they can get backward compatibility. For example in INI file if you add more sections or keys because you have implemented something new the file will still remain compatible.

On the other end, bynary files are uncomprensible from human, are mainly incompatible from version to version, difficult to manage and repair other than having dedicated applications, difficult to debug when there is an error.

In the case of track designer and subsequently using track files in track game, if you go with binary format you will need to keep aligned the 2 world (creating and using) while with text files you can implement new features while still compatible and have time to improve your reading even if the creator has added new features. New features will just be ignored by the reader because not aware of them. Also no need to use any personalized function if you use INI files because already there.

Anyhow, this is just my opinion. Take the direction you prefer and I will love it. You already give us a great pleasure with your track editor. If this is the start I cannot imagine the end :o

Ciao
Eros

[ErosOlmi]

Regarding UBOUND problem, I will post a complete new 1.7.0.0 by tomorrow.

Ciao
Eros

[Simone]

Hi,

Michael very nice tool it's simple and very intuitive to use Nice work. ;)

Ciao,
Simone

[ErosOlmi]

My new creation

[ErosOlmi]

Another one that cover more floor part.

[Simone]

My first Creation ;D

[ErosOlmi]

JPG Simone, JPG.
So we all can preview your creation

[Simone]

Hi,

Sorry :P

Simone

[Michael Hartlef]

Hi Eros,

I had allready movement of the camera doen and also saving to a text based file. :-[ But I overwrote it somehow. Just wanted to let you know that I will implement your suggestions.

[Petr Schreiber]

Hi Mike,

that is great news, thanks for your work!


Petr

[ErosOlmi]

Thank you mike !

[ISAWHIM]

Ok, I have not added anything into the editor yet, because I am still determining what elements will be needed to make the track edit a full track edit program. I am not talking about making it into a 3D object creator, but there are other elements, other than model-position and rotation, needed for editing the track.

So... Here is what I have come up with so far. (This assumes that we will use a path of some sort.)

The editor needs three sections.
- CITY EDIT (Lays city-blocks, based on style selected in TRACK EDIT.)
- TRACK EDIT (Lays track-blocks, and determines the STYLE for the track.)
- PATH EDIT (Creates "Valid" track-blocks, required for custom track-blocks.)

NOTE: Only custom track-blocks can have a path edited. Otherwise that would interfere with game-play. Paths will be a one-way creation without the original edit file. The game will only use the original paths for normal game-play. Any path can be used for a custom made game/track.

Track blocks have these elements.
- Block ID (Unique)
- Display Name (For user only)
- M15 Model File Name (For loading)
- Orientation Base (Starting natural orientation. XYZ of the M15)
- Value for city-block fill. (City-block is not added in track-edit mode, but a value/type needs to be here.)
- Point Data (Indicates IN/OUT and PATH, in and out can be swapped.)

Point Data contains these elements.
- IN (Starting natural order, counts as a "JOINT" for connecting other track blocks.)
- PATH (Interpolation points between IN and OUT, not used for positioning blocks, but relevant for track-edit mode.)
- OUT (Opposite point in natural order, counts as a "JOINT" for connecting other track blocks.)

The track-edit needs three objects before an actual track-edit can begin.
- STYLE (City type, places the "LANDMARK" dead center, and track/city is built around it.)
- START (Determined by the "STYLE" selected, and may be placed within 10-2-2=6 blocks of the "LANDMARK".)
- TRACK (A valid track component, which has a IN/PATH/OUT data.)

NOTE: The "City/Track", assumes a full city-border which will consume the outer ring of the 10x10 max-area. The "Landmark" does not have to be centered, but has to be within the city border, as the track does. These two limits, determines where a valid starting position may begin, as well as the start-IN and start-OUT location.

The track will be built in order, from (START - OUT) to (START - IN), only allowing track-blocks that are available to be connected, available for selection. The track can not be "ADDED" to the list of available tracks, until the track is complete. An incomplete track may be saved, just not loaded into the game for play. A track is "COMPLETE" when it connects to (START - IN). Natural order is, Start-Out to Track-In-Out to Track-Out-In to Start-In. Only the TRACK - IN and OUT may change by the orientation. The START - OUT will always be the EXIT to the track, while the START - IN will always be the ENTRANCE to the FINISH-LINE. Orientation of the START will be limited to rotation only, no swapping direction.

Track blocks that are not START, can be rotated or swapped. Rotate is limited to 90 degrees. Swapping can only be done LEFT to RIGHT and FORWARDS to BACKWARDS. Swapping will not change the order of the points, only the location which the points connect. IN will still be IN and OUT will still be OUT.

When a track-block connects to another track-block, it can only connect at the IN or OUT joint/point. This is where point-order and IN OUT will reverse-order or reverse-flow. Since the START-OUT is where the track is built from... The piece being added will stay the same order, if its IN is connected to the START-OUT. If swapped or rotated, you are attempting to place a TRACK-OUT onto a START-OUT, and the points/joints will be swapped.

Ok... You finish the track-edit, and now you can go to the city-edit.

In the city-edit, depending where you have laid the track, your limits are shown as available spaces. The border is also pre-filled with city-blocks that can be changed, but can't be removed. (This could be the city-wall, but I imagine that having city-blocks would help cover the horizon which would normally fall out of view.)

The city-block "Fill" blocks, will be available for any track-block that has a compatible value. There may be 3 types of fills available for the same track-block, but not all fills will fit over all track-blocks.

The odd part will be the "POINT - EDIT" mode.

We can edit any points in a path, because we will have the edit-file for that path. Users, if we allow it, will only have the ability to edit the paths on those same track-blocks, but only for the game they save, not the paths that the game uses. Any-who... (I'll explain that later.)

For the paths, this is what I was thinking...
Just like the track, you first setup the NATURAL - IN and OUT. Those are limited to the designated locations for the block-shape. (EG, on a single 100 x 100 square, they are at the half-way point on each side.)

You are limited to 9 interpolation points in addition to the IN and OUT joint for each block-size. (100 x 100 = 9 points), (100 x 200 = 18 points) (200 x 200 = 36 points)

You are limited to a maximum angle between points. (This limits creating "Z" and "L" 90+degree points. This also makes point-direction/flow possible to detect.)

You are limited to a minimum distance between points. (This limits creating impossible paths, and ultimately with the angle limit, stops useless points from being created which would potentially slow down the game.)

You are limited to a maximum distance between points. (This limits unusually long paths between points, and limits point-crowding on one path.)

You are limited to a maximum path-length. (This is the distance between the furthest points on any path from IN to OUT.)

You are limited to a maximum path-connect quantity. (This limits single points from being used to connect to multiple points that would kill AI decisions. No-one needs to think that hard at an intersection!)

All that being said...

Here is what you CAN do...

Drop nine points in the block-area. Connect paths from IN to POINT-A, POINT-B. Connect POINT-A to POINT-C. Connect POINT-B to POINT-D. Connect POINT-D and C to OUT. (That leaves five points unconnected. They go away, you are left with four points, and two paths. (IN - A - C - OUT) (IN - B - D - OUT).

When the AI hits IN, it can see A and B, and will select one way to go. (It might think about it, or it might just be random.) From B, it can see IN and D, but D is marked as "Forward", from "IN", by the point data for this segment. etc...

The point-editor will "look" at the created paths, and set-up the flow of each point as forward and backward, from IN and from OUT, so the points can be read in any direction, by reading the first-set of values, or the second-set for each point, depending on the way the track is entered. (Which is determined by the track-edit, and thus the importance of points and the track as one edit.)

This gives us the ability to make forks with up to three directions, and the ability to create a wide-open area with solid obstructions to avoid. (Trees, barrels, poles, fences.) Without having to use complex in-game processing, other than... Do I go left, right, or down the middle?

This should work nice in 3D, (Using height, not just XZ) to create places that AI and the camera would not normally handle without points. (Loops, high banked walls/turns, over/under paths, and backwards travel while still progressing forward on the track.)

Ok, now my head hurts... Time for me to figure-out how to move 3D things with the mouse, in 3D.

[kryton9]

Jason, now my head hurts... I am glad I am not in the code or design team. Lots of good thinking it seems to me from what I read while my head spun :)

[Michael Hartlef]

Hi Jason!

Ouch, that is quite a mind challenging idea. And complicated. As it seems that you need this for implementing the AI, I can easily say that I won't be able to write such a tool.

Half of the stuff you said I don't understand or is unlogic to me. Also I think that there is a lot of time needed to implement the features you want so I can easily say that I won't able to do this from the timeframe alone. Plus my knowledge.

I'm sorry that I can't help you anymore to build such a tool. Someone else has to do it.

I hope we have someone here who can do it.
Michael