LV
4
After working on the migration, I can now give a more practical comparison between RmlUi and TOP’s legacy UI system.
The video may be a little long, and I probably didn’t cover every part of the skin. Creating the UI shown in the video took around 7–9 full working days. However, the visual skin was only one part of the work.
Note from here and below ai generated based on my .md too lazy to write them 
so u can skip all and jump Final Verdict and the video
Note from here and below ai generated based on my .md too lazy to write them
so u can skip all and jump Final Verdict and the video-----------------------------------------------------------
A complete migration also required changes in MindPower and the client for:
A complete migration also required changes in MindPower and the client for:
- Mouse press, release, hover, and capture states
- Preventing UI clicks from moving the character
- Tooltips and item comparisons
- Drag-and-drop between different forms
- Keyboard shortcuts and text input
- Window resizing and viewport clamping
- 3D character, creature, boat, and item previews
- Loading, shutdown, relog, and device-reset behavior
Therefore, RmlUi should not be considered a simple replacement skin system. It is closer to a new presentation layer for the client.
Quick Comparison
Area | RmlUi | Legacy TOP UI |
|---|---|---|
Simple fixed form | More setup | Usually faster |
Large UI project | Easier to maintain | Becomes repetitive |
Form layout | RML/HTML structure | Lua and native widgets |
Styling | Shared RCSS/CSS | Mostly images and per-control setup |
Button states | CSS hover, active, focus, disabled | Usually sprite frames or separate images |
Image requirements | Fewer images | Often needs images per button, page, and form |
Dynamic sizing | Naturally supported | Requires client/MindPower changes |
Scrolling | Built-in behavior | Usually requires dedicated controls and code |
Live editing | RML, RCSS, and palette can reload | Requires a custom client implementation |
Runtime themes | Easy after the theme system exists | Requires more form-specific work |
Dragging forms | One reusable controller | Commonly implemented per form |
Text counters | One reusable behavior | Usually implemented separately per input |
Tooltips | One shared presentation layer | Often connected directly to native widgets |
Input ownership | Can be centralized | Distributed across forms and managers |
Localization | Better Unicode and font support | Limited by old text paths |
3D previews | Still requires native integration | Already integrated with native widgets |
Gameplay logic | Existing managers remain authoritative | Existing managers and forms are coupled |
Future renderer changes | UI documents can remain unchanged | UI rendering is tied more closely to DX9 |
Learning curve | Requires CSS, RML/HTML, and C++ | Easier for existing TOP developers |
Testing requirements | Large input and lifecycle matrix | Existing behavior is already known |
Advantages of RmlUi
1. Far fewer image assets
With the legacy system, a developer often needs separate image states for each button, form, tab, background, and page.
With RmlUi, CSS can provide:
With RmlUi, CSS can provide:
- Background colors
- Borders
- Hover states
- Pressed states
- Disabled states
- Selection states
- Spacing and alignment
Images are still useful for item icons, skill icons, portraits, and decorative artwork, but they are no longer required for every basic control.
In this migration, the asset cleanup removed more than 1,300 unused or duplicated legacy UI images. The remaining assets were organized by purpose and converted to PNG.
In this migration, the asset cleanup removed more than 1,300 unused or duplicated legacy UI images. The remaining assets were organized by purpose and converted to PNG.
2. One style can update many forms
The migrated UI uses a shared semantic theme. Colors such as panel backgrounds, buttons, borders, text, selections, scrollbars, and modal backdrops are defined centrally.
Changing one theme value can update the complete UI instead of editing every form individually.
The current implementation supports:
Changing one theme value can update the complete UI instead of editing every form individually.
The current implementation supports:
- Satisfy
- Ice Blue
- Midnight Cyan
- Royal Blue
- Custom RGBA colors
- Live theme preview
- Saved user themes
- Reset to the default theme
It is important to clarify that theme switching is not completely free. The theme system and selector must be implemented once. After that, new skins generally do not require form-by-form C++ changes.
3. Live UI editing
RML, RCSS, and theme files can be reloaded while the client is running.
This makes it much faster to adjust:
This makes it much faster to adjust:
- Form dimensions
- Positions
- Colors
- Padding and spacing
- Font sizes
- Scrollable areas
- Button states
- Compact and wide layouts
C++ changes, new fonts, and native rendering changes still require a rebuild or restart.
4. Better reusable UI behavior
Instead of implementing the same behavior separately for every form, RmlUi allows shared systems for:
- Panel dragging and viewport clamping
- Character counters
- UI hotkeys
- Confirmation and quantity dialogs
- Item tooltips
- Input focus
- World-click blocking
- Context menus
- Theme colors
This requires more architecture at the beginning, but reduces repeated code as the migration grows.
5. Better separation between UI and gameplay
In the migrated client, RmlUi owns presentation and interaction, while the existing native systems remain authoritative for:
- Packets
- Inventory rules
- Item validation
- Equipment
- Storage
- Guild permissions
- Quest data
- NPC trading
- Stalls
- Skills
- Character models
- Maps and navigation
For example, RmlUi displays item tooltips, but CItemCommand::AddHint still creates the actual tooltip information. This avoids rewriting or accidentally changing game rules inside RML or CSS.
6. Better input handling
The migration introduced centralized input ownership:
- RmlUi receives the event first.
- Remaining legacy interfaces receive it when appropriate.
- The world receives it only if no UI consumed it.
This solves common problems such as:
- Clicking a button and walking at the same time
- Losing a mouse release after dragging
- Hotkeys activating while typing
- Clicking through a modal
- A form underneath another form receiving input
The legacy UI can also be fixed to handle these cases, but the work is usually spread across more individual forms and managers.
7. Better text and localization support
The RmlUi path supports FreeType fonts, UTF-8 text, clipboard input, IME handling, font fallbacks, and the current project’s Arabic shaping and bidirectional text bridge.
The legacy client can be modified to support these features, but its original text path was more limited and closely connected to the old font renderer.
The legacy client can be modified to support these features, but its original text path was more limited and closely connected to the old font renderer.
Disadvantages of RmlUi
1. The initial integration is significantly harder
A proper implementation needs more than RML and CSS. The current client required:
- A custom Direct3D 9 RmlUi renderer
- Texture and geometry support
- Scissor handling
- Render-state restoration
- Mouse and keyboard routing
- Unicode and IME handling
- Resize handling
- Device loss and reset handling
- Correct initialization and shutdown order
For a small number of ordinary forms, this initial investment may not be justified.
2. Each form can involve three layers
A migrated form usually contains:
- RML for its structure
- RCSS for its appearance
- C++ for data, events, and native game integration
This is cleaner for large systems, but it can feel slower than creating one fixed legacy form—especially for developers already familiar with the old Lua form system.
3. CSS and layout knowledge are required
A developer needs to understand:
- Element flow
- Flex layouts
- Padding and margins
- Relative and absolute positioning
- Overflow and scrolling
- Hover, focus, and disabled states
- Viewport behavior
CSS can save a lot of time, but only after the learning curve.
4. Complex game UI is still complex
RmlUi does not automatically solve:
- Inventory transaction rules
- Cross-form item dragging
- 3D character previews
- Minimap and world-map rendering
- Creature and boat previews
- Native item and skill overlays
- Server confirmations
- Equipment attachment effects
In this project, these systems still use native game managers and renderers behind RmlUi-owned viewports.
5. The current DX9 adapter has visual limits
The temporary Direct3D 9 renderer supports the basic features needed by the current UI. Advanced effects such as filters, complex masks, layers, shaders, and certain transforms are intentionally avoided.
These features should wait until the future bgfx renderer supports and validates them.
These features should wait until the future bgfx renderer supports and validates them.
6. Migration requires extensive testing
A form is not complete just because it looks correct. It must also be tested for:
- Windowed and fullscreen modes
- Compact and wide resolutions
- Resize and viewport clamping
- Mouse capture and drag release
- Keyboard and text focus
- Escape and Enter behavior
- Relog and map switching
- Repeated opening and closing
- Device loss and reset
- Missing or long localized text
- Clean client shutdown
- Server failure and confirmation states
The visual work may be fast, but achieving full behavioral parity takes considerably longer.
Final Verdict
RmlUi is probably not worth the migration if:
- You only need a few simple fixed forms.
- You are satisfied with the existing appearance.
- You do not need runtime themes or live editing.
- Your developers already work much faster with the legacy system.
- You do not plan to modernize the client further.
RmlUi is probably worth it if:
- You want to create or maintain a complete modern skin.
- You need dynamic and responsive layouts.
- You want fewer form-specific images.
- You want scrolling and reusable controls by default.
- You want live RML/RCSS editing.
- You want multiple runtime themes.
- You need improved Unicode and localization.
- You want clearer separation between presentation and gameplay.
- You plan to move the renderer to bgfx, DX11, or Vulkan later.
For a simple form, the legacy system remains faster. For a large, evolving UI, RmlUi requires more effort at the beginning but offers much better flexibility and long-term maintainability.
My conclusion is that RmlUi is worth using for a serious client modernization project, but it is not a shortcut. The visual skin can be completed relatively quickly; the real work is achieving full gameplay parity, stable input handling, correct native integration, and reliable behavior across the entire client.
My conclusion is that RmlUi is worth using for a serious client modernization project, but it is not a shortcut. The visual skin can be completed relatively quickly; the real work is achieving full gameplay parity, stable input handling, correct native integration, and reliable behavior across the entire client.
