stefanhendriks / dune-ii---the-maker Goto Github PK

Normally you would see some text while territories are captured, but there is no such thing.

Rendering issue?

Now that culling is done, the application segfaults when scrolling up beyond the map's upper bound. Haven't taken the time to pinpoint the reason.

That said, I think it's preferable anyway that Map holds a vector of Cells, rather than an array of static size, holding potentially half-loaded Cells.

Ie, make sure all gfx/audio data is outside dat files.

Then imagine a few mods:

• original dune 2 gfx
• enhanced dune 2
• sega mod
• d2tm (default)

Something to play with, how would it look like in a battle when dead bodies stay and broken tanks on the sands? Instead of fading in a fairly short time?

When a carry-all picks a Harvester from a refinery, and drops it off somewhere on a spice field. The harvester is rendered nearby the Refinery (harvesting animation). Once the harvester starts moving, it is rendered at the correct position:

While working on #59 , i noticed an issue when using lower resolutions (or simply having too many maps).

The map list would continue off-screen. There is no way to scroll.

• Add ability to go through map list (scroll? paginate?)

Example, on 640x480:

When changing the velocity, it does not seem to matter in the movement of the camera. It also does not seem to accelerate, although the code implies it should.

This commit 2e726e9 seemed to introduced it. Try to cherry-pick again.

The initial position of a unit is not marked as occupied if the unit isn't moved.
This allows other units to move through them.

This bar should be full-width (till sidebar)

After #49 the next challenge is to support multiple resolutions.

This will break a few things still, because the in-game UI is fixed, see the gfxinter.dat file.

The viewport rendering (map tiles, units, etc) draws outside of the game window.
It's neater to use set_clip_rect() to draw exactly within the allowed bounds.

This also helps to get support at a later time to draw window-in-window.

800x600 was worked on, but not working properly entirely (ie MENU looks off, as for skirmish , etc)

• Main menu is not centered
• Mentat is not centered #52 (delegated for v0.6.0 or later)
• House selection is not centered #123 (delegated for v0.6.0 or later)
• campaign missions screen (#54) (delegated for v0.6.0 or later)
• Mission is complete window is not centered (delegated for v0.6.0 or later)
• detect higher resolutions
• in-game GUI should be flexible (ie, sidebar, etc)
• Skirmish menu #59

Ofcourse, keeping support for the official 64x64 (or rather 62x62) maps... but for skirmish we could go up to way higher.

The dimensions could be fixed, or flexible. Perhaps up to 512x512, or even 1024x1024?

Would need to think about how to go about the minimap.

• concentrate functions and data in one class (ie get rid of cCellCalculator, merge it within Map class)
• get rid of the generic iCellMake and such functions (in common.*)
• bullets should use absolute position coordinates & being rendered with them
• structures should use absolute position coordinates & being rendered with them
• units should use absolute position coordinates & being rendered with them
• particles should use absolute position coordinates & being rendered with them
• render maps < 64x64 maps properly on minimap (can be further improved, see #162)
• test campaign missions
• test skirmish missions (respect their dimensions - see Skirmish map: "Cliffs of Rene")
• make it explicit what the map playable borders are (basically dimension - 2) and what the data dimensions are (ie, the 64x64 vs 62x62 case)
• generate random maps of 128x128 instead of 64x64 (later configurable after #106 )
• bigger maps than 128x128? (deferred to #161)

Perhaps per mod? (See #78)

Ideas:
Add music.ini, defines per file the kind of music. With default being "peace mode"?

After seeing: https://www.youtube.com/watch?v=PPup1yeU45I&list=PLlrATfBNZ98dudnM48yfGUldqGD0S4FFb&index=82

It might be a good idea to go through the current singletons in the code and check if they are set up correctly.

At the moment, a house == color. Meaning, if you select 2 Harkonnen CPU's , they will both play as 'red'.

This is very confusing.

Especially if you're playing Harkonnen as well...

Now it is hard-coded which buildings and units are available after placing a structure. This can be made more flexible, (like work has been done for upgrades in #68). Then, it can be configured.

Once that is possible, it could even be moved outside code and into a rules.ini kind of thing?

Obviously they can't, but their logic is flawed. When a Harvester is attacked, it will try to retaliate. THis might work for foot units (soldier, trooper, etc). But for other units this is stupid.

...although it doesn't have a virtual destructor.

deleting object of abstract class type ‘UnitMoveBehavior’ which has non-virtual destructor will cause undefined behaviour [-Wdelete-non-virtual-dtor]

This is the destructor in question:
UnitMoveBehavior::~UnitMoveBehavior() { this->map = NULL; this->layer = 0; }

What's the point of setting layer - a short - to 0? Setting map to NULL does not delete the object on the heap. I would suggest using smart pointers over manual memory management.

Ie, two trikes, move to same destination. 1 trike cannot move further due other trike blocking. Then, move air unit over trikes. The 2nd trike will move over the first trike.

I guess because of the shared 'occupied' map data.

The sidebar is based on the old C&C days. The sidebar in C&C Remastered is better, it removes the need for scrolling through lists (and using the scroll buttons). It is a bit wider, but it is not so high which makes up for it.

Todo

• upgrades into separate list (as C&C3)
  • configure all upgrades in code
• Do not render build count for upgrades
• When structure is placed evaluate upgrades.
• When structure is destroyed evaluate upgrades.
• When upgrade is done, re-evaluate upgrades.
  • test & make sure it wont delete previous upgrade
• move minimap up
  • when no minimap available, show house emblem
• minimap: Without an outpost and/or sufficient power, the radar screen will only show friendly buildings.
• move Order button to the sidebar
• credit-bar (centered) should be 8 bit
• sidebar should show power usage
• spice usage
• minimap: when clicking on it, you should jump properly to the place you where clicking... (regression)
• topbar, show information? (selected structure? power/spice usage?)
• Upgrading should limit build options (ie CONSTYARD upgrading should limit CONSTYARD items to being built) - and show it on icon
• When a unit/structure is built, the related UPGRADE cannot be executed (and should show it)
• bug: Cancel placement does not work
• bug: when building house of IX, it adds Deviator/Devastator etc even when no heavy factory is present.
• mouse selecting/rectangle draws over sidebar

Example of C&C (Red alert) Remastered sidebar:

In the feature branch (shroud) we see this a lot happening. Last task should fix this. (ie, camera should never go below 1 and exceed (MAP_WIDTH - 1)). etc.

Now, when using multi-select/dragging the Harvesters get caught up. This shouldnt happen - more modern like (and expected) nowadays in RTS games.

• build from palace
• deploy at palace
• saboteur moves fast
• saboteur can enter structure -> #150
• saboteur destroys structure it enters -> #150
• autobuild next (WONT DO)

I noticed that the maps in /skirmish are not showing up in the list:

• build death hand from palace
• 'deploy it' (specify location)
• death hand fires from Palace to location
• make landing a bit fuzzy (no sniper nuking)
• big explosion
• auto-build next death hand (Will not do for now)
• cells further away from impact receive less damage

Sometimes - not all times - when a building gets destroyed by enemy fire, there is only at the top-left corner an explosion. No other effects.

It is not always reproducable, so this requires a bit investigating.

Like Dune The Golden Path does, or C&C Remastered. Using mouse wheel, scrolling causes map zooming.

With Allegro 4 it should be possible using stretched blitting.

Progress at 23-08-2020 -> https://forum.dune2k.com/topic/20495-d2tm-progress/?do=findComment&comment=400042

To get a feel what we're aiming at, see https://youtu.be/ORB9bmFvSEY?t=301 and https://youtu.be/8UxdPwxDTEQ?t=386

TODO

• units do not attack when ordering units to attack a zoomed in structure
• When zoomed (in or out), ordering units to attack makes units freeze. (ie, they stop moving, even when half-way cell, and they don't do anything else. They won't attack, nor move). When resetting zoom (with z), then clicking on structure to attack works as expected. (related to above?)
• crashing when zooming too far out
• drawing of shroud broken
• Windtrap drawing broken
• Drawing of placing structure is not taking zoom factor into account
• When zoomed out, the repair icons on structures are still 100% which looks weird (icons are bigger than structure)
• Windtrap shadow offset is wrong when zooming.
• Prebuild animation is still not zoomed
• Particles (smoke, explosions, etc) that have been placed are not rendered at the correct place when zooming
• minimap broken (rectangle no longer rendered, and clicking on it does not work as expected)
• use own stretch blit that does a bit more safety checking?
• Explosion particle itself is ok, but the extra flare, with additive blending looks off
• Test sound effects (distance volume feature)
• Zooming should not move lists in sidebar (cripples easy scrolling, but it will be replaced by #68)
• Rendering Rally point should work with zooming
• squish particle renders not properly (wrong coordinates?)
• some explosions seem to be wrong (tank big explosion)

New controls use that (ie in C&C Remastered). Hold mouse button, then move mouse (from the position the mouse was held) and use the difference to tell how to move the viewport.

todo

• Hold right mouse button, and move causes map to move to that direction.
• the further away from the point you started dragging mouse, the faster the movement should be
• should take zooming factor into account (#65)
• should not deselect selected units

With some own dune rules in mind, I want to be able to switch between the two so we can play the original campaign (and have a close experience to the original game) and a new experience.

• can build from palace
• spawns Fremen (group of units) at random place at map (2 / 3 light, 2/3 heavy fremen units) (ish)
• auto builds next (WILL NOT DO, you have to explicitly build it (as in Dune 2))

Coming from #57 .- if resource loading is uncoupled from Allegro specific libraries, we could upgrade Allegro or move to SDL or alternatives more easily.

Even Allegro 5 does not have .dat files, so either way we have to get rid of .dat files.

Unit coloring works, but it does not respect the shade of the source image.

From #49 , currently the menu looks like:

(resolution 1280x1024).

Atleast:

• top bar should cover whole width
• "Skirmish" should be centered
• Map list should be at the right
• Map preview should be at the right
• Start and Back options should be at the bottom
• Background/Dune picture should be somewhat right/down from center

As if the shroud revealing mechanism somehow does width - 2 or something?

Currently, the mouse is rendered on the screen via the buffer. Ie, it is not using the OS rendering of the mouse which is regardless of the FPS performance.

The desired situation is where the mouse is rendered via OS, so that even when the game performs badly the mouse stays responsive.

Also, the mouse 'feel' would be respected if using the OS cursor instead of FPS based. It is noticably different between windowed mode and fullscreen mode.

This could be achived by using Allegro's mouse routines

When using windowed mode, the mouse respects the 'feel' (speed, etc) from the OS. When in fullscreen the mouse seems to be over sensitive (feels off).

I would expect the mouse to feel like in the OS.

Related to #49

Best would be to center the mentat, perhaps move the buttons at the bottom right?

Same goes for house briefing (ie, when you select a house you get a brief description about what this house is about):

Related to #49

Now in 800x600 it shows like:

Better would be centered, possibly with a background color matching the yellow color we already had?

After scrolling I regularly see lines between the tiles, as can seen below.

D2TM is tightly coupled with Allegro 4.2. Since that Allegro version is deprecated and upgrading to a newer Allegro version (5.x) is as painful as migrating to any other library, it becomes clear that the dependency on Allegro 4.x has to be weakened to make a migration possible and less painful.

Current known dependencies

• ALFONT (might be fine to leave this, and migrate this along with Allegro, this seems kind of trivial?)
• ALMP3 (can be removed, feature is broken anyway) (#388)
• FBLEND (equivalent Allegro 4.x functions exists) (#387)
• .dat files (ALDATA?) -> #385

Once the above has been done we can start working on #386

Also, once we can migrate to another library, it would become much easier to make D2TM cross-platform (#58 )

fix compile warnings

And not only the actual limits of the data.

An in-game options menu is lacking.

as you can see a white box is around the infantry. This should not happen.

In fact, units don't seem to clear shroud for any side but the human player. We want to have a shroud map (revealed or not) data per player. (which we also want for a fair AI player, don't we? :))

They seem to have forgotten who the enemy is, they won't attack eachother nor the human player.

This applies to units and structures.