xRpgMaker Development Log, Update to Day 6

[xywhsoft]

I had three days off on New Year's Day, and I needed to spend time with my family. This is the fourth day of the development log.

I used about 4 hours to finish the ListBox, it has no inheritance relationship with ScrollView, it is a separate element, now it works well and I think it is more powerful than the ListBox of Win32SDK.

After that I continued to update the TileSet editor of xRpgMaker and the development was unhindered after the component had been completed.

I created a neat data structure that holds the various settings for the blocks, as well as data for up to 15 AutoTiles. Of course as I mentioned in the development log on day one, if I put the Tile data in here as well, it would cause the embarrassment of not being able to align the data, so this part was implemented separately.

After that is the saving and loading of the data, since it is neat data it can be loaded and saved directly, this part of the code was done in only about ten lines and it worked fine, I did some security checks to make sure it doesn't load bad data.

A few more trivial events are handled so that they can fill in the data structure I created, and now all the functionality except for TileEdit is available.

Next I started working on the TileEdit user interface element. I didn't have much time left, it was now 5am and I needed to go on a break before 7am so I wouldn't have enough energy to cope with the work.

TileEdit is quite a bit less difficult, mainly because he has up to 5 working modes, which is purely physical work, as well as, I need additional art work, which is something I'm not good at, but the good thing is that the workload is not too much and I can finish it during the day.

Time went by fast today, maybe because the previous ListBox development made me feel like I hit a wall and never found a better solution, but today I was very focused on solving it, and before I knew it a long time had passed, but the progress improvement was also very obvious, at least now DBEdit.exe has a little bit of initial functionality.

I'll probably start with a LineEdit UI element in the next few days, now that I'm becoming more and more aware of how uncomfortable it is to lack an editor-like control, even if I start with a simplified version that can only be edited in a single line, it can still greatly improve the experience and presentation of DBEdit.exe.

After these four days of development, XGE's ability in user interface is basically confirmed, and I will use it more confidently to develop other components afterwards. Unfortunately, xui's UI elements are now a bit low, and this part may take a lot of time to perfect. Moreover, xui is still drawn frame by frame without using dirty rectangle technology, which wastes a lot of unnecessary performance and needs to be improved, but it is not a high priority, because from my experience developing DBEdit, it can take this level of performance pressure.

I've recently seen some discussion in the community about FreeBasic's development of user interfaces, and we all hope that FreeBasic will provide a more modern approach to interface development. In fact, DirectUI is a direction worth trying, and the Win32SDK is already outdated, no matter how well packaged the interface library is, or how difficult it is to make up for its backwardness by developing a Visual Basic-like designer.

Layout system is a very important component, with an excellent layout system, the development interface does not need to be visualized, just follow the layout flow, the problem of typography can be easily interface, while the interface scaling is handled very easily.

In this part I would like to recommend a DirectUI library from China, which is excellent and surpasses even most commercial DirectUI solutions in terms of capability: http://www.xcgui.com/

In the future maybe I will also develop a DirectUI library, but of course this is a blank check, because I always have a lot of work and the project is always crowded, now my focus is still on top of XGE, including xRpgMaker which is actually a DEMO of XGE, just that he has a lot of potential, so I develop it separately.

Today access to FreeBasic's website is very stuck, I do not know what is the reason, later I will upload yesterday's development of j

Translated with http://www.DeepL.com/Translator (free version)

[jj2007]

Dear xywhsoft,

Congrats to your progress, you are starting an important project. May I suggest one thing? If you click here, you will realise that soon your log will fill the whole Game Dev sub-forum. Perhaps it would be sufficient to have only one thread "xRpgMaker Development Log"?

Keep up the good work!

[xywhsoft]

Dear xywhsoft,

Congrats to your progress, you are starting an important project. May I suggest one thing? If you click here, you will realise that soon your log will fill the whole Game Dev sub-forum. Perhaps it would be sufficient to have only one thread "xRpgMaker Development Log"?

Keep up the good work!

Yes, I will merge these development logs.

[xywhsoft]

Day 5

Today I ran into a series of problems that eventually led me to announce that the xRpgMaker project would need to be postponed for a while.

Initially, I was going to develop the TextBox user interface element, a very technical little thing that is a huge mountain that every DirectUI author must climb, but the requirements were also so extensive that I was going to implement a simple one-line editor version and then add support for various formatting, such as a numeric editor, and other user interface elements.

In fact I had developed something similar before and it couldn't be considered a very intense challenge for me, maybe 2 days I could get it done, but when I started working on it, I realized something serious.

Back when I was developing the Text module, the FontDriver part had considered providing support for both Unicode and ANSI, and that goal was achieved, but the other modules of XGE were lower on UNICODE support, although the other parts only needed a simple transcoding, since there was no processing of text involved, so I didn't worry about that and acted to get Unicode done in just two hours.

But the editor magnifies this drawback.

Initially, the encoding supported by XGE was GB2312, a Chinese encoding, and I only needed to support thousands of characters and ANSI, Unicode, and Utf-8 encoding conversion to make XGE work well, and the font was small only needing about 200KB, but as I promoted XGE to the English partition, being able to support as many languages as possible became a problem that had to be solved.

Why is this problem so serious?

As I said before, for ordinary APIs, support for multiple encodings is just an extra layer of transcoding, the difficulty of implementation is very low, because it does not involve the processing of text, but the core of TextBox, is a large number of text line data management.

For example, I want to save the location of the cursor, it should be a character location, that character location where?

So I need to traverse the current text line, get the relative offset coordinates, and then the cursor will be drawn, and the width of different characters is different, I can use equal-width font to reduce the difficulty, but I still need to distinguish, those characters occupy a full frame of space, which characters occupy half of the space, which involves the identification of the coded content.

If I hadn't standardized the encoding, there would have been extra work for this part, as I did for FontDriver. Of course FontDriver I had good reasons to design that way, because adding an encoding working mode allowed me to choose a smaller font, but TextBox was different, I could only use one encoding for the kernel, and for the future health of this project, Unicode was the only choice.

And XGE's project is built on ANSI.

I can certainly continue to update xRpgMaker, the pre-development is going very well and I'm nearing the end of my first page, next is MapEdit so I can get the first DEMO that runs.

But this pursuit of progress leads to another very serious problem, when XGE is updated, I have to refactor this project as well, because the kernel coding changed.

This is very frustrating.

So I had to choose to release both 1.1 and 1.2 of XGE before xRpgMaker continued, and a little later I will release 1.1 and then go full steam ahead with 1.2.

The milestone for XGE 1.1 is to enrich the XUI controls, which will be achieved when the LineEdit UI element is complete.

The milestone for XGE 1.2 is to completely refactor XGE and develop it based on Unicode.

After this, I will continue the development of xRpgMaker.

Thanks to everyone's support, this project is not over, just the focus is back on XGE for now.

Here's the latest screenshot with the LineEdit UI elements, as you can see, it works very well with the input method (this is halfway through development, after which I will implement the candidate list rendering directly within XGE).

Translated with www.DeepL.com/Translator (free version)

[jj2007]

Here's the latest screenshot

Did you forget the link?

Re textbox: On Windows, using a Unicode edit control is very easy with CreateWindowEx(). Putting Ansi text inside is easy, too, as you just must convert to UTF-16 with MultibyteToWideChar.

[xywhsoft]

Here's the latest screenshot

Did you forget the link?

Re textbox: On Windows, using a Unicode edit control is very easy with CreateWindowEx(). Putting Ansi text inside is easy, too, as you just must convert to UTF-16 with MultibyteToWideChar.

I was so tired yesterday that I forgot to check the screenshots of the post.

I will make up the screenshots here.

There are some new changes today, and in general, LineEdit is getting closer to the most basic requirements to be usable.







This is the effect achieved so far, compared to Notepad.

It's not complete yet, the list of candidate words is still displayed outside, I'm in the process of integrating it into the game's UI.

Currently all major game engines use a similar scheme, some less functional engines leave it outside, which may cause problems with splash screens, game screen switching, etc. due to input method window creation when playing in full screen.

Translated with www.DeepL.com/Translator (free version)



It is not a good idea to use the editor provided by Win32SDK in the game, it is really very well developed and reinventing such a wheel does require a very big effort.

But Win32SDK's editor has a lot of problems.

One obvious problem is that the game screen interacts directly with the graphics card, so the user interface elements provided by Win32SDK can interfere with the game screen, especially if the refresh of the two is not synchronized, which is why few games use this way of implementing the interface.

The game screen is always being refreshed, and even if there is a solution with dirty rectangle technology, the application in games is very limited.

Another problem is that in full screen, the status window of the input method and the candidate word window will interfere with the full screen game when they are created.

Another problem is that the events in the game are allowed to penetrate, for example, an event UI system does not handle, then he will penetrate layer by layer to other UI elements or logical parts of the game, while Win32SDK does not have a similar mechanism, when a Win32SDK element cooperates with the game, it will produce very serious interference.

For example, after the TextBox gets focus, the keyboard events of the whole game will be eaten, and if you want to recover, you have to modify the state of the TextBox by additional code.

In addition, the style provided by Win32SDK user interface elements is difficult to change, and the efficiency of GDI drawing is extremely low, which are difficult to overcome, and the difficulties faced when trying to integrate into any game are often greater than rebuilding a new user interface element suitable for use in the game.



DirectUI uses a similar idea, and this is currently one of the dominant directions in interface development (the other direction is HTML+CSS)

Translated with www.DeepL.com/Translator (free version)

[jj2007]

It is not a good idea to use the editor provided by Win32SDK in the game, it is really very well developed and reinventing such a wheel does require a very big effort.

But Win32SDK's editor has a lot of problems.

Good points, thanks. You have obviously much more experience in game dev.

[xywhsoft]

Day 6

After 3 days of work, LineEdit is finally ready to be made available, and I will be ready to release the XGE 1.1 development kit.

This will also take about 3 days, including creating examples, testing most of the functions in the engine to make sure they work properly, and adding two relatively simple user interface elements: the progress bar and slider.

Here's what I'm planning so far.

Version 1.1 should be a quick transition version, because soon I will start refactoring 1.2, and 1.2 will be the next stable version, but in terms of features, 1.2 should not have any major updates, mainly code refactoring as a whole, and priority to provide perfect Unicode support (the future core of XGE will be completely built on Unicode encoding)

After that is version 1.3, this version mainly I want to provide a file package system, a kind of file package managed by number, support LZ4 and LZMA compression, can easily convert the game material directly into game objects, can use reference count to manage the loading and release of material.

The milestone goal of version 1.4 is to provide a Key Value database, this kind of database is now more and more applied to the game, I have not yet determined a good technical solution, the most likely is to implement one themselves, the alternative is google's key value database system or directly built-in lua scripting engine or dukJS, the reason why these programs just The main reason for these options is that they are too big, I am still committed to making a lightweight 2D game engine, and compressing the first 500KB is still one of the main goals.

The milestone goal for version 1.5 is to provide an animation system, a flash-like animation editor that generates some kind of animation format that can be easily played out in the game, which will simplify the game developer's task of creating the game.

Version 1.6 will be the stable version after that, I will check the engine source code comprehensively in this version, optimize it as much as possible (for example, the FontDriver in the Text module still does not implement the Fast interface), and provide perfect bilingual help documentation.

This is my plan for the XGE engine after this, before this, xRpgMaker will be in a dormant state, before continuing to work, I need to polish my tools.

Translated with www.DeepL.com/Translator (free version)