w23 / opensource Goto Github PK

There are people who want to run this on their machines.
Figure out how best to make release binaries for this project for at least Windows.

Some textures look corrupted. Don't know why.
I mess up DXT reading?
I mess up calculating VTF offsets for DXT data?

It is trivial to do, but still somewhat time-consuming.

It doesn't seem to use landmark entities like other games do.

Valve wiki confused me by showing skyboxes from outside, rather than inside.

O(N) is too slow

limit is somewhere between 30-50 maps

what could be done:

• optimize textures (rgba32 is too fat, 16 bit looks dirty, maybe some etc1 naive on-the-fly compression?)
• optimize geometry (how?)

The ability to save a high-resolution top-down image of the entire loaded world would be very cool, the output would look something like these:

http://www.nextdimension.org/bmrf/Black_Mesa_Research_Facility_HL_Map.jpg

http://www.unleashthedog.net/uploads/HL2_overview.jpg

Currently for development vpk files contents are mounted using vpk_fuse. This is not cool. I cannot release like this.

• read directory
• sort entries
• open archive fds
• ICollection interface to alloc IFiles

Some textures are visually missing, although loading log reports no missing materials or textures. Primary hypothesis is that I'm missing something important from Patch materials, because their supports is a hack even compared to other materials support.

• load maps in parallel
• load assets in parallel
• convert textures to ETC in parallel

There's like 30% occupied and everything else is a void. Size guesser overestimate.

The entire Half-Life 2 mesh is like 5fps on AMD Radeon FURY X. This is unacceptable.

Things to try in no particular order:

• map frustum culling
• face frustum culling
• bsp node frustum or pvs culling
• dynamic per-material batching of visible faces
• pre-sort vertices by material for VBO offset 64k splitting
• one giant VBO for the entire mesh
• skip material and lightmap textures for distant maps, do baked color instead
• combine most popular regular material textures into atlases to avoid splitting draw calls

Allocating oddly sized strings on Stack breaks alignment. This explodes on ARM.

src/bsp.c:263: Error: no visible faces found
src/bsp.c:646: Error: bspLoadModelPreloadFaces() => BSPLoadResult_ErrorFileFormat
src/bsp.c:912: Error: bspLoadModel() => BSPLoadResult_ErrorFileFormat
src/OpenSource.c:275: Cannot load map "d1_eli_01": 2

That way no retarded pre-extraction of files would be needed

Figure out what's the deal with Portal 2 map positions and landmarks. Reading _entry _exit doesn't lead to continuous maps for some reason.

reverse-engineer lightmaps

There are a lot of materials that aren't found on loading. I expect that these are stored within bsp files themselves.
Pakfile lumps are zipped or something, so will have to figure that out too.

Portal 2 uses that. For some reason. I have no idea. Every other game uses VPK2.

This is so old!

Later Valve games like Episode One have larger part of maps made out of models rather than bsp geometry. Without models these maps look unnatural and empty.

Load one map per frame. Don't make user wait ALMOST 4 SECONDS to load the entire HL2 world.

Atto doesn't have proper support for macOS yet. Do it.

• too yellow or green in places
• weird green bands

In map d3_citadel_05

Apparently skyboxes are materials. And it is purely accidental that their textures can be loaded directly by concatenating bk.vtf or alike to material name.
This material is different. Need to load its material properly

I have an idea how to remove the skybox areas.

First, find the leaf in which info_player_start's "eyes" are placed. Push this leaf to the stack.

Then, until the stack is empty, repeat:

1. Pop leaf from the stack.
2. Mark popped leaf.
3. For each visible leaf of that leaf:
   3.1) Check if it's not already marked. Proceed to 3.2 if it's not.
   3.2) Push the visible leaf to the stack.

Then, make a mesh containing only polygons from the marked leaves.

What do you think?

У меня есть идея, как убрать скайбоксы.

Сначала, найди тот лист, в котором находятся "глаза" info_player_start'а. Положи его на стек.

Затем, пока стек не стал пустым, выполняй следующие действия:

1. Возьми лист со стека.
2. Отметь его.
3. С каждым видимым листом у этого листа:
   3.1) Проверь, не был ли он отмечен ранее. Если нет, переходи к 3.2.
   3.2) Положи этот лист на стек.

Потом, сделай меш, содержащий только полигоны из отмеченных листьев.

Как тебе идея?

This might come in handy.
Also, collisions to make it more "playable".

Blend skyboxes of two maps closest to the camera

To achieve that one would need to parse *.dem files, extract player positions and play them.
Some sad facts:

1. There is no publicly available specs on GoldSrc (most speedruns are made playing original HL, not Source) *.dem format that look legit.
2. Source *.dem format (https://developer.valvesoftware.com/wiki/DEM_Format) suggests that the file itself contains just network packets, and common sense tells me that those should contain only player commands (input) and not much else. If this is right, then there's no way to extract player position without implementing the rest of the engine. Oh my!
   (However, Source SDK sources contain DEM parser that suggests that there really is a way to extract just a player position without processing actual input, but I went no further in my preliminary investigation)

I don't mean coplanar surfaces from different maps.
Should either tweak z-buffer params, or completely change z buffer approach to something less naive and more contemporary.

if there are more than one map present as a parameter, link only specified maps, ignoring everything else

Current orange-brown background color is sad.

• BGRA8 d2_coast_11
• BGRX8 d1_canals_13
• RGBA16F d2_prison_01
• Texture "skybox/sky_day03_06Brt" not found d3_citadel_05

Allow specifying memory limits at run time

А то молочные реки, кисельные берега какие-то.

should really consider into parsing bsp data and retrieving the complete main tree, and nothing else

• Lab is misplaced at the very beginning https://youtu.be/2Uaft9KNkm0?t=2h31m48s
• Like canals-something map: https://youtu.be/2Uaft9KNkm0?t=2h37m13s
  I expect that there are some stale landmarks left from earlier iterations of level development.

Will need to have a mechanism for ignoring/fixing those.

• landmark ignore list?
• injected landmarks?

Portal 2 doesn't use neither named landmarks nor changelevel triggers with explicit next map name.
Instead, being completely linear, it uses global ordered map list with each map having info_landmark_entry and info_landmark_exit entities to stitch consecutive maps.

GL_CLAMP_TO_EDGE doesn't help.
Valve wiki suggests that it's a DXT issue (?).

Probably limited to this:

• file reader
• file mmapper
• gl function loader
• make sure that atto doesn't have any obvious bugs on windows
• grab mouse + WM_INPUT

https://youtu.be/2Uaft9KNkm0?t=1h46m39s

I have seen this as a mesa bug previously. But most likely this is an issue with wrong indexes or vbo.

The code doesn't build in VS2017 on Windows 10 Home. This is quite odd, the project should have been easy to migrate.

the include paths are not set up right (so it cant find the headers), and app_windows.c/.h are missing.

I can't wait to get this working though!

Apparently, there's a recommended optimization: cut half of the skybox texture and visibly shrink the remainder (bottom half of skybox texture is invisible usually), see https://developer.valvesoftware.com/wiki/HDR_Skybox_Creation#Creating_PFMs

Fixing this requires $basetexturetransform support, see https://developer.valvesoftware.com/wiki/$basetexturetransform