Play Mapper (WIP)

[thaaks]

      Probably.. But for clarification, so when you load the example maps animations aren't enabled ?

That's what I meant. Animations are disabled in PBM when I load my own map. 

      It's be out of sync in the edit display.  What I mean, is it's only a valid representation of one portion of the editor view. Since the editor will (more than likely) to be running in a higher resolution than the final game display (and the backdrop image).   Hence the discussion about a 'game' view port view.

Yup. You know what I mean and you'll get it working, I'm sure  ;D

[kevin]

           
       

That's what I meant. Animations are disabled in PBM when I load my own map.

           This should work in V0.46.   However when you export a layer,  all that's exported is the layer properties and the array of tile data.    So if you export/import layers from some other source manually, then you lose the animation definitions.   Since they're not stored in a layer, they live in the map

          Currently tacking some limited backdrop support into it.   See piccy.

[thaaks]

Oh yes!  ;D

[kevin]

Play Mapper V0.46 (Alpha)

     This version corrects the layer properties problem when importing levels in previous.   It also includes a very basic 'WIP' backdrop/game prop's window which is currently titled GameScene properties.  It's only about %10 implemented, so it preview only.. (ie naff)


     Be forewarned however, this is an pretty early Alpha.  There's bound to be bugs with the animation stuff.  So take it easy initially,  If you notice some sequence of events thats causes an error with Anims, then make sure you mention it bellow!



Included Stuff
* Basic tools (Tile,Line,Box,Circle,Brush)
* Block import
* Multi tile Selection
* Multi Layer Support
* Layer Tools (Resize/Scrolling)
* Brushes
* Context driven pop up menus (right click)
* Load/Save Format (hunk based.)
* Undo support (100 or so levels)
* Mini Map Preview / Overview
* Import Level (packs) as Brushes
* Import Level (packs) as Layers
* Animation Support
* Map Conversion




Future (only if there's demand)

* optimize layers
* Block Export (combine, stream/optimize)
* Add some future proofing for PB1.7x map libraries



Download

  old alpha removed.   Try the Play Mapper Tools board.


   Play Mapper Reload Library

[kevin]

PlayMAPPER Awakenings  

    Being one of the oldest PlayBASIC tools around i've been meaning to update this for contemporary editions of PlayBASIC, but haven't had the time.   Mixed feelings about at today,  for an alpha there's a lot of stuff in it, things I'd long since forgotten.  My favourite would have to be focus on brushes, but the controls are somewhat hampered by the mixture of custom and windows gui together.  The only solution would be to remove the legacy WinGUI stuff just as the other tools have long since done.    

    From a code perspective, it's a relatively clean program, but parts of it could be reduced though by swapping methods to more modern approaches.  All of the  PB helper tools moved away from WinGUI stuff long ago.  But it's a lot more ingrained in this program.  So can't just chop it out and roll a few replacement functions and hey presto.    There's a lot of code tied up in gathering where the input comes from and how to react to it.   Consolidating everything into one system would make it a lot easier.  

    I think this is a situation where something like the Action GUI framework would work better.   It's a far cry from flexiGUI in scope, but the input / response processing is much easier.    You create a 'window' of a particular class and the GUI calls your methods on demand.   Hiding much of the classic creation/trapping  and GUI resource management away.    That'd probably be a 25% reduction in size straight off the bat.  

    Only issues that come to mind handling the gadgets and building a replacement menu.    The menu stuff is really interesting as moving to a CallFunction approach would again reduce the code footprint by incorporating  the catch and call process into the GUI directly, or via a message.    It's just a matter of defining a destination function that exists.  The refresh will call it.   Really like the idea of  externalizing the definitions of much of that stuff.  

    So menu  could be a simple as

Code Select Expand


[File]
->New Map onclick="GUI_NewMAP"
->Load Map onclick="GUI_LoadMAP"
->Save Map onclick="GUI_SaveMAP"

[About]
->PlayMAPPER onclick="GUI_ShowABOUT"



  etc..  

[BlinkOk]

download link doesn't work

[kevin]

  PlayMAPPER - Menu Mock Ups  

   PlayMapper uses the discountinued WinGUI library with the window menu, right click popup menu and scroll bars.   So to get rid of it, means coming up with replacements for at least those components, all of which I've got sitting around (in one state or another) from other tidbit projects over the years.    The menu stuff is  standard one used in all the PB tools bits, but the popup menu had to be harvested from the IDE prototypes.   Took a little bit of messing around to convert, but ended up Frankenstein all the bits into something that feels like a replacement.

   The classic drama when building GUI stuff in code, rather from some designer before hand (which then builds the code/data for you) is you've not only got to create the 'things',  but trap any interaction with those things.      So if you have a menu, you've not only got to define the structure of the menu, but write some code to react to any clicks those buttons.     Which is generally nothing more than a Select / Case statement, but it's still another little chore to program and maintain.   The replacement menus use the callfunction behavior.   So once defined, the render function calls target function for you.  Which will mostly remove the need for manual interaction.   I say mostly, as there's bound to be some situation where some alternate behavior is preferred.  Always is.  
 
   Bellow is just a mock up of the components running together.  



Form Issues

   All the forms in the old version are created in code on demand.  As such, tweaking the cosmetics is tedious as all hell.    Starting to have ideas of using legacy visual basic as make ship form designer for GUI stuff PlayMAPPER.   The VB6 forms seem pretty easy to parse really, they're just a list of variables after all. it wouldn't look anything like the VB form, but laying them out code is not a lot of fun.    The benefit also is the form and be edited at later date.  

   Update: An hour or so ago it was a theory and now there's a very basic VB6 form parser up and running.  The parser just runs through the VB form and grabs the fields that are useful in the PlayBASIC world.  Doesn't support controls, but you can get the form easy enough.    Controls aren't any more difficult, there just more parsing.   The parser dumb and dog poo, but will do the job.   The current thinking is that it'll spit out a some type of square bracket markup to store the fields in.   Then the host program loads the texts and calls a decoder.  The decoder could make the flexi window and controls etc.    Dunno well that'd work, but it should be viable. 

    The second picture shows the VB6 form designer and the PB app running in front. The parser skims the form and gets cherry picks the caption, back ground colour, size etc from it.

     

[ATLUS]

Looked very nice!

[kevin]

  Simple Vb6 Form Conversion V002

        Yesterday the Vb6 form parser was only able to parse basic info about a single form.   The next step has been to include support for some controls.   So far,  it's limited to only Picture &, Label controls.   The Picture control turned into a little more work than I was expecting,  since VB6 stores the actual picture data in a binary pack file.  Luckily with a little guess work about the structure,  it's able to rip the included pictures out and save them back to disc.   Otherwise you'd have to do this by hand, no thanks..  The ripper is pretty dumb, it simply assumes the pack file formats, rather than knows it.  So any  other type of data and it'll  have no idea about.  But it shouldn't matter for this.  

         Bellow we can see the VB6 form designer and PB parser with a mock render of the dialog.    


Form Conversion V003

          Got a bit further with this tonight,  ran into a few snags with some of the properties in the controls being a right mess.  So weeding out the stuff  I don't need, which is about 75% of them really.   You could probably knock together a placement tool and get much the same result.   None the less, it now supports LINE, TEXTBOX, BUTTON and some alignment do dads.   

         The display routine is purely mock up in these demos.    Undecided about what it'll export today.  It'd be easier to keep FLEXI GUI in PlayMAPPER, since it's all ready done, but as with any GUI change, this means a lot of tweaking or down right replacing slabs of GUI code.    The other option,  would be to build (mostly harvest) the gadget controls from FLEXI and drop them into an ActionGUI styled framework, then pull the 'editor' code out of current PlayMAPPER and drop it into a fresh new project, bit by bit.    They're both pretty time consuming, but can't help feeling the latter would give a better result, but probably  be just a shakey in the short term.   
 
         If we stay with Flexi, then to get the most out of the dialog builder it needs to export 'gui code' as is.  So it'd basically spit out a set of functions that create the window, trap the events and manage the properties for you.    Which is basically would visual basic does for you, effectively Hiding the mandate nature of trapping clicks.   

[kevin]

PlayMAPPER - Menu Test

        Had some time tonight to try dropping the menu parts into the existing project.  It's not until you really dig through the entire projects source, that the size of it really hits home,  weighing in somewhere around 23->24,000 lines.    Since the Menu is string based, the defines are set out in some data statements with a little routine to construct it.    Even though it's less code than the old WinGUI setup, there's still a LOT of data/code to set up.   So just making the table alone, probably took and hour or so.  

        Patching the rendering together is pretty straight forward, the problem has always been working out the context of the click(s) in relation to the various components.  As such, there's all this man handling wedged into the trapping to try and guide the response.  It sorta works, but there's combinations where it's more work than it need be. A by product of that, is some things that I wanted to include,  just didn't work properly, like the key controls.   The main components used in the project were built long before to the V1.64K though, so the methods the code uses, really reflect this.  

        Anyway, here's a bit 'as is' shot of the menu running in PlayMapper.  In this version, only the main File menu options are actually hooked up to the action functions (the code that actually does the thing).   So it's even less useful than before, but it does work.   The PopUp menu replacement doesn't seem to want to display for whatever reason and there's the same click catching issues in this version.        


Form Conversion V004

        The form parser works good enough for the time being, supports pretty much the basic properties of all the standard VB6 controls.  Form Labels, TextBox, Buttons, Check/Option Boxes, Vertical & Horizontal Sliders, Pictures/Image boxes and some primitive controls.    It can't render all these accurately in the display mockup, but it parsers the properties into the structures ready to do something with them.   For most PB tool styled projects,  Labels, TextBox, Buttons, Checkbox , Sliders and pictures are more than enough really.  

[kevin]

 PlayMapper - Menu / Dialog Conversion

   The project is simmering along,  since last time all the menu stuff has been hooked up and pretty much most of the legacy WinGUI stuff removed.  Been able to strip it all back to about 20K lines, and pretty happy with that.  There's  seems to be  a reasonable amount of  legacy code that could be removed also.    The program uses a much older version of the Flexi library (whatever revision it was back in 2008).   Flexi's had various key additions since then,  most to how it works, such as call backs to user defined functions and stuff like support for the treating the screen as special window.    They're both very handy, the latter removes a big part of the 'click' and focus issues from multi windowed apps.  

    So my first port of call has been swap to the most recent addition of flexi, this is where all the parts collide.  Current all dialogs are hand programmed in PlayMAPPER.  Building everything in code is tedious.. very tedious.. Since the newer version of Flexi support call backs,  it'd be much easier to define the form in VB6 and run the importer app and have it spit out the required data/code.   Doing this means translating the parsed form /control dialog info into Flexi gadgets.  Flexi wasn't meant to be map to Windows GUI one to one, so something won't translate over.   But ideally the closer the better.      

    In today's little experiment, we're importing the VB6 form, then  building a working flexi window with controls from it.  The styling is different, but the basic functionality is much the same.  What's missing the behaviors behind the interactions with the Clicking the various gadgets.  These will have to be programmed, much as they are in VB.   But If with the call back system, it should be possible to stream line much of this code.    But anyway, bellow we have piccy of the VB6 form editor and flexi window next to it.  



     Go here (VB6 Form to Flexi Conversion ) for more stuff about the VB6 to Flexi form conversion.