corwinn / h3r Goto Github PK

These contain most of the game bitmaps.

Perhaps I shall dynamically increase them on an "as needed" basis; then:
0: music; 1: UI fx; 2+: game fx; or 0, 1: music (fade in/out), 2:UI, 3+: game fx?

The most re-written class around. Text services.

No point. Their data is going to a texture atlas. Besides if one bitmap format converter is needed, that's exactly what shall be done: one bitmap format converter function at one place.

File IO won't block the UI.

Prepare build scripts. Read the license info. Add questions. Etc.
.
The cross-compile adventure never ends.

Desing and implement.
window: the puzzle pieces are clicking in place
UI: Button: initial =>

It shall show a dialog asking if the user wants to stop the program, and act accordingly.
Try using the newly discovered (new for me) capturing lamdba as a function pointer for event handling. See what happens: do I need Command or not. Not yet. UI: Multicast Delegate for now. The trick can't be used: no pointer to template :).
the worst message box ever
The Delegate issue is resolved.

Figure out the .fnt file format of the game.
Text Rendering: initial
Text Rendering: initial part 2
TODO: And just use the sheer brilliance called "FreeType" - as an option.

Text. Buttons. DialogResult.
the worst message box ever

Multi-platform Thread object.

Threaded dual FIFO should be ok.

A.k.a. a build system.

Virtual File System interface - abstract away file and directory access:

• VFS: 1/5 - stream that
• VFS: 2/5 - LodFS
• VFS: 3/5 - SndFS
• VFS: 4/5 - VidFS
• VFS: 5/5 - Resource Manager

Required by String and others.

A pre-requisite to the Resource Manager.

Render the UI as a single VBO:

• make more windows
• make the texture atlas cache Texture Cache: initial
• finalize the UI design (the object-oriented one)

1st the project needs error handling:

• out of memory policy: default - exit()
  //LATER - ask the user to resolve it or exit()
• file IO policy : same as above
• log policy : default - exit()
  //LATER - silence

For the file stream.

Index the game and create the basis for the graphics view.

UI: Label: initial

Because everything is better when its sorted. I'm not joking.

Design it.

So I can parse things and log errors.

Needed by the Resource Manager.

Smallest map - all kinds of terrain; walk around with a single hero (limitless movement points).

Select a map and load it.

• ui: newgame: 3/300 :)
• ui: new game dialog: text layout preview
• ui: new game dialog: all main elements + a working button group
• ui: new game dialog: ready to enumerate the .h3m
• See (hopefully) for yourself: h3r-static-windows-x86_64-0.2-alpha

Parse gzip data on the fly.

So I can see what the game bitmaps look like, whats their contents, to guess how are things organised, etc.

1. Define the game actors, classes, etc.
2. game: foundation
3. game: thoughts
4. game: where the numbers are coming from; and its possible modifiers
5. game: map description
6. h3m_ffd: done

Design and implement. The docs are pretty clear:
https://docs.gl/gl2/glDrawArrays

C++ doesn't make any promises in regards to the order of static initialisation, but it does so for members.

It feels like I'm weaving a very intricate pattern - its diagram time again - part of complexity management; do you know what happens if I don't manage complexity? - "infinite project" happens :)

All diagarams

• Async: clarify: diagram: complete, for now
• Design: Resource Manager diagram
• Font Engine
• UI: a picture slowly focusing
• UI: identified the reason for the partial rendering
• FFD
• os: windows: eliminate a deadlock

Contains game-play masks?

Bitmaps.

1. SDL2: initial
2. waving: mainwindow+music+q_key
3. one: main window using resmanager
4. two: window: the puzzle pieces are clicking in place
5. three: "Open GL" 2.0 enters the scene
6. four: window: bridge; heres why

Create a simple and readable way to describe the different file formats of the game:

• code unification: no need to have five parsers, but five descriptions
• understand the unknown data fields
• a pre-requisite for the game model

1. game: map description
2. ffd: begin a formal specification
3. ast initial
4. it began parsing
5. parsed upto Terrain

Abstract away the game data. Define a plug-in interface for custom resource managers.

Like: sound quality, etc.

While the .fnt parser isn't strictly required, it can help bring the remake closer to the origin.

UI:Button hover: highlight demo

Start the main menu music and button sound fx.

Using my favorite diagrammer, clarify what blocks depend on what blocks, and observe the most obvious too-stupid-decisions.

When you put something in RAM remember where you put it.

Milestone 1: Render the main screen. Bridge. "SDL2" initially.
Milestone 2: Create the game model. (because otherwise boredom would slow down the project)
Milestone 3: View 1 - UI.
Milestone 4: Controller Main - UI.
Milestone 5: View 2 - map.
Milestone 6: Sound.
Milestone 7: View 3 - battle.
Milestone 8: AI.
Milestone 9: Hi-scores.
Milestone 10: AI scripting.
Milestone 11: View 4 - campaigns
Milestone 12: https://heroes3wog.net/did-you-know-second-edition/
Milestone 13: Multi-player.
Milestone 14: Plug-ins. (sound, resource manager, renderer, AI)
Milestone 15: Mods. (should take 2 minutes if all of the above are designed correctly)
Milestone 16: New things. (see "Whats the new?" at the file "project")
Milestone 17: Map editor.

Versioning: 0.* - alpha releases; 1.0 - proof of concept; 1.1* - to be decided.

The above could be wrong, could be right. I have no idea. Only one way to find out.

Introduce multi-threading. Needed by the log service and others.

So I can test my new code prior or after it being written.

Query for max texture size. And handle the non-power of two textures case.