My Classic 2D-Tile-Map-Editor
BlitzMax Forums/BlitzMax Beginners Area/My Classic 2D-Tile-Map-Editor
| ||
| I still working on my oldschool 2D-Tile-Editor, a little tool to create 2D-Tile-Based Level-Maps including a little Tile-Paint-Application, so I can change any Tile Images on the fly. The main layout (amout of Tiles ... Colors) is inspired by the NES system. One Tile-Set (256 Tiles) for Background-Tiles, and another Tile-Set (256 Tiles) for Sprite-Objects. The Tile dimensions are 8x8 Pixel. Later I will add an Sprite-Paint-Animation Tool, and a special Layer for editing and positioning movable Objects. I look forward for any kind of comments :) Every Day I will upload a updated Version on my webspace. (source-code and all Data) Some parts of my source-code are little bit chaotic. http://www.axgs.de/blitzmax/MapEditor.zip Happy Coding :) Alex |
| ||
| I made some major changes. slowly it goes forward. :) http://www.axgs.de/blitzmax/MapEditor.zip |
| ||
| Not Found The requested URL /blitzmax/MapEditor.zip was not found on this server. ^^; |
| ||
| Oh sorry, so I restored the download. Not all features are implemented yet, but tile-paint works (only with pixel), load/saving Map & Tile Data into one file. http://www.axgs.de/blitzmax/MapEditor.zip Alex |
| ||
| As I always say, you can never have too many global variables :-) |
| ||
| I know, global variables is a bad coding style :) perhaps I fix this and make my Code more object-orientated. |
| ||
| I killed some global vars .... yuhu I made a Type (Class) for the Map-Data itself ... and some methods to operate with the map-data. http://www.axgs.de/blitzmax/MapEditor.zip |
| ||
| thanks Brucey for the hint. The Code is much cleaner !!! Friendly Greetings Alex |
| ||
| Heh, I've tried it on debian8, win7 and win10 and they all take over a second to 'refresh' the tile under the mouse. The mouse pointer is fluid but the tile updating under the mouse is dog slow :/ Looks like the beginnings of a cool little editor :^) |
| ||
| on my machine it is not slow (win 8.1) I only have a intel g3220 CPU (very cheap one) and only Intel-HD GFX Onboard. |
| ||
| Programming is fun isn't it. Works ok on one machine and not on another :D Both computers here ( asus nv56z with debian and win10 and the other custom machine with an i5 that has win7 ) have nvidia gpus, the laptop has a gt650m and the box has a gtx750. They have the latest gpu drivers etc. Strange eh. |
| ||
| Your DrawTile() function uses DrawPixmap(), which is exceptionally slow at rendering. On my 2.7 Ghz i7, it spends on average 55ms in your DrawTile() function alone. To run at 60fps, you generally expect the *whole* frame rendering to be performed in well under 16.6ms. |
| ||
| I am little bit confused. On my Intel g3220 (dualcore 3.0 Ghz CPU) the mainloop takes 16 - 22 ms. On my Latop Intel i3 = max, 22 ms hhhmmmmmmmmm. I Dont know. |
| ||
| I set my Build-Options to "non-Debug", with Debug it takes 100 ms. |
| ||
| I never use Debug-Build. |
| ||
| Same speed here. Takes over 1000ms. i7cpu |
| ||
| Without a doubt the problem will be the use of drawing pixmaps. If you can convert to using TImage(s) then all will be good. |
| ||
| and how I can write a Pixel to an Offscreen Image, I found no solution. |
| ||
| I set my Flip() Statement to Flip(0) and the mainloop runs at 9 ms, with DrawPixMap. I have no performance problem. |
| ||
| I have no performance problem. DrawPixmap is notorious for really (really) poor performance on different GPUs. One card may be fine, the next it is terrible. Therefore, use something other than DrawPixmap. |
| ||
| and how I can write a Pixel to an Offscreen Image, I found no solution. There's always a solution ;-) Let's first start with the underlying mechanics of TPixmap and TImage... A TImage represents a handle to a gpu texture. The inital underlying pixel data of a TImage would have come from a TPixmap. Even with LoadImage then pixel data is loaded as TPixmap. When it comes to drawing a TImage for the first time then the TPixmap is converted and uploaded to the gpu - giving the TImage a gpu texture handle. Any successive drawing of the TImage will then merely set the gpu to use that already now existing texture to be rendered. Moving on to the TPixmap... A TPixmap is cpu side memory to represent pixels of an image. They are fast to manipulate with cpu code but cannot be used by the gpu without being converted to a gpu texture ( as above ) - in fact they are the best way to create you own custom images, as you are doing in your editor. Now, each time you use DrawPixmap then the whole process of converting, creating and sending pixel data to gpu to create a texture to be rendered has to be done. Multiplying that process by any amount gives a significant speed loss. Knowing that information... A solution would then be to use TPixmap only for actually manipulating pixel data, but then use DrawImage to draw everything. I've not looked at your code so I don't where you would make changes to take advantage of my suggestion. I don't mean for you to convert every TPixmap to a TImage every frame, but only convert the single TPixmap that has been changed during that frame. Everything else on screen would then be drawn using TImages. I believe you can use LoadImage(myPixmap,....) to quickly get a TImage from a TPixmap, then you can use DrawImage to render it each frame. Once you work out a clean method using the suggestion above then that 9ms will become 0ms - and probably very close to ( if not ) 0ms for everyone else too. |
| ||
| I took a look into the Modules-Source (that I never done before) ... and I saw that the TImage Type has a member of "pixmaps". My solution is following: LockImage(tileImg) WritePixel(tileImg.pixmaps[0],xpos,ypos) UnlockImage(tileImg) now I can paste my Tile with "DrawImage" at amazing speed. (8 times faster then before). But there is a fault with MASKED blitting (but I can fix them) Thanks for testing my source :) Alex |
| ||
| 8 times faster then before Yay! ;-) |
| ||
| But I saw that the "LockImage" Function returns the pixmap. ehh cool. So I fixed it !!!!! I am using now "DrawSubImageRect" instead of "DrawPixMap". |
| ||
| Woohoo! Well done! I now have 0 ~ 1 ms per frame on both machines, and all OSs ;-) |
   |