valoeghese / 2fc0f18 Goto Github PK

Spread light one block further into opaque with forced termination to make it easier to recalculate. Either that or make single block breaks update lighting faster by having an immediate step for updating 1-2 block (PREFERRED). Lighting seems to take up quite a bit of time on the thread

can I reduce time relighting one chunk by more intelligently handling relighting the chunk? Perhaps abuse the fact that only the segment directly against the chunk from neighbours has any chance of propagating into the chunk to reduce calculations

also when am i making fov a setting

Especially noticeable when placing blocks

Is not to do with the size of the world's map of chunks (which remains about 120 most of the time - most loaded are not rendered or lighted due to load stages), but I wonder if chunks are being stored in memory too long. Like, after unloaded the instance still exists.
Or maybe OpenGL objects aren't being properly deleted? I use glDeleteVertexArrays, do I need to use glDeleteBuffers as well?

Directly enabling mipmapping causes a weird fog-like effect due to the colours from other parts of the tile atlas filling the gap. If we were to readd it, we'd have to change something.

1. Separate chunk batching for lighting and main rendering not going to do this for now. I moved some stuff to shaders and that makes skylight better, but I think improve the lighting engine first
2. Change chunkloading to be LAZY. Unload chunks from a far distance.
3. If they don't already, Make chunks only save if they're modified. Even if new gen. this would break population, so alas I can't do this
4. Do not load chunks on the lighting Thread. DO NOT LOAD CHUNKS ON THE F***ING LIGHTING THREAD. (Only care about them if they're loaded) (edit: censor)
5. Change chunk loading to force less stages surrounding the player. Only care about RENDER and TICK, and have an UNLOAD distance. POPULATION and GENERATE will come naturally as chunks give their requirements.

So when they’re short they don’t get squished

Chunk-adding after loading is staggered now due to threading stuff and funi limiting code
Therefore we can probably afford to do away with that nonsense from the old chunkloading method. It will clean up a lot to just add it to render list

The types of chunk error found:

• Chunk interaction and content not matching what should be there, not matching what is rendered (the rendered is usually the actual correct one). The chunks here are likely not in RENDER phase and there is some other chunk at the location? probably chunk-chunkmesh desync? shooooooould be fixed. EDIT I encountered this a few days ago
• Chunks not rendering. Content of these chunks is usually also incorrect for the region. This one is the most common at the moment, especially after respawns.
• Chunks generating differently to how they should, but still rendering is fine and matches content (haven't encountered this type for a while)

This could be related to one of the other errors.
Perhaps this is related to the generated long keys for chunks in the world - maybe multiple chunks end up generating the same key or file?

by detecting if an existing vertex will be reused (smartly, not through brute force caching). Then just use the index thereof.
Retrieving the index might actually require a hashmap actually, but we can just have it temporarily through the gen buffers method

Also moving text or a square could be done potentially through transforms rather than rebuilding meshes lol

Should be simple

valo code at its finest

chunks around 0,0, or merely around spawn, actually not sure where, like to... uh... populate a completely different chunk instead. Like how tf. Is it bc of how I handle bitshifts or something? or threading issues?

As in chunk input

Spells go brrr

Followup to the chunk I/O From
Thread-> Executor. Once this is done I can turn the render distance up

I have foley sounds I made but haven't added them

I changed the tile pos to start in corner now make it work p0nki

Will be handy to have

Indeed

I propose two byte arrays in each chunk for sky and block lighting. Lighting is calculated as part of the "population" phase of a chunk, after world gen population occurs. Light emitting blocks are limited to 15, not to be limited to minecraft, but to limit the amount that light can overflow into neighbouring chunks.

Sky light will be simple at first: [0~15] above the ground based on time of day, 0 below ground. Block light will also have a simple propagation algorithm initially. All opaque blocks will completely block light. The actual light at a position is Math.max(sky, block). When a light source is removed, the entire chunk's light is recalculated, and any neighbouring populating (not generating) chunks have their light recalculated.

As lighting is populated, this means it will be stored with the chunk. A new ByteArrayDataSection will be used for lighting, and will store in the format sky, block, in the same order as tiles.

We use the current min and max global lighting as the min and max represented by 0 and 15.
Sky lighting will still be calculated the same.

Exception in thread "main" tk.valoeghese.sod.exception.SODParseException: Unhandled IOException in parsing file .\saves\save_1\c-21.9.gsod
at tk.valoeghese.sod.BinaryData.readGzipped(BinaryData.java:130)
at tk.valoeghese.fc0.world.save.Save.getOrCreateChunk(Save.java:233)
at tk.valoeghese.fc0.world.GameplayWorld.getOrCreateChunk(GameplayWorld.java:83)
at tk.valoeghese.fc0.world.GameplayWorld.loadChunk(GameplayWorld.java:138)
at tk.valoeghese.fc0.client.world.ClientWorld.loadChunk(ClientWorld.java:30)
at tk.valoeghese.fc0.world.Chunk.getChunk(Chunk.java:556)
at tk.valoeghese.fc0.client.world.ClientChunk.south(ClientChunk.java:89)
at tk.valoeghese.fc0.client.render.model.ChunkMesh.buildMesh(ChunkMesh.java:70)
at tk.valoeghese.fc0.client.world.ClientChunk.rebuildMesh(ClientChunk.java:122)
at tk.valoeghese.fc0.client.world.ClientChunk.writeTile(ClientChunk.java:52)
at tk.valoeghese.fc0.world.gen.GenWorld.wgWriteTile(GenWorld.java:21)
at tk.valoeghese.fc0.world.GameplayWorld$GeneratorWorldAccess.wgWriteTile(GameplayWorld.java:354)
at tk.valoeghese.fc0.world.gen.generator.ScatteredOreGenerator.generate(ScatteredOreGenerator.java:24)
at tk.valoeghese.fc0.world.gen.generator.ScatteredOreGenerator.generate(ScatteredOreGenerator.java:8)
at tk.valoeghese.fc0.world.gen.WorldGen.populateChunk(WorldGen.java:100)
at tk.valoeghese.fc0.world.GameplayWorld.loadChunk(GameplayWorld.java:160)
at tk.valoeghese.fc0.client.world.ClientWorld.loadChunk(ClientWorld.java:30)
at tk.valoeghese.fc0.world.Chunk.getChunk(Chunk.java:556)
at tk.valoeghese.fc0.client.world.ClientChunk.west(ClientChunk.java:111)
at tk.valoeghese.fc0.client.render.model.ChunkMesh.buildMesh(ChunkMesh.java:68)
at tk.valoeghese.fc0.client.world.ClientChunk.rebuildMesh(ClientChunk.java:122)
at tk.valoeghese.fc0.client.world.ClientChunk.refreshLighting(ClientChunk.java:157)
at tk.valoeghese.fc0.world.Chunk.lambda$null$0(Chunk.java:197)
at tk.valoeghese.fc0.client.Client2fc.run(Client2fc.java:137)
at tk.valoeghese.fc0.client.Main.main(Main.java:8)
Caused by: java.io.EOFException: Unexpected end of ZLIB input stream
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:240)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:117)
at tk.valoeghese.sod.BinaryData.readGzipped(BinaryData.java:115)
... 24 more

what

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
at tk.valoeghese.fc0.client.world.ClientChunk.writeTile(ClientChunk.java:35)
at tk.valoeghese.fc0.world.gen.GenWorld.wgWriteTile(GenWorld.java:21)
at tk.valoeghese.fc0.world.GameplayWorld$GeneratorWorldAccess.wgWriteTile(GameplayWorld.java:395)
at tk.valoeghese.fc0.world.gen.generator.CityGenerator.generate(CityGenerator.java:126)
at tk.valoeghese.fc0.world.gen.generator.CityGenerator.generate(CityGenerator.java:12)
at tk.valoeghese.fc0.world.gen.WorldGen.populateChunk(WorldGen.java:100)
at tk.valoeghese.fc0.world.GameplayWorld.loadChunk(GameplayWorld.java:199)
at tk.valoeghese.fc0.client.world.ClientWorld.loadChunk(ClientWorld.java:30)
at tk.valoeghese.fc0.world.GameplayWorld.chunkLoad(GameplayWorld.java:306)
at tk.valoeghese.fc0.world.GameplayWorld.updateChunkOf(GameplayWorld.java:274)
at tk.valoeghese.fc0.world.player.Player.move(Player.java:89)
at tk.valoeghese.fc0.client.world.ClientPlayer.move(ClientPlayer.java:40)
at tk.valoeghese.fc0.world.entity.Entity.tick(Entity.java:52)
at tk.valoeghese.fc0.client.world.ClientPlayer.tick(ClientPlayer.java:152)
at tk.valoeghese.fc0.Game2fc.tick(Game2fc.java:68)
at tk.valoeghese.fc0.client.Client2fc.tick(Client2fc.java:159)
at tk.valoeghese.fc0.client.Client2fc.run(Client2fc.java:125)
at tk.valoeghese.fc0.client.Main.main(Main.java:8)

Mipmapping seems broken

Language name can be stored as a property in the file language.name=Language Name or something

It's currently two black triangles lol

Flickers between them

Parallel Worlds have different WorldGen subclasses, whereas Planes use different Z offsets of the same WorldGen subclass

together they comprise the multiverse of 2fc. Will be important for progression in the RPG side of the gameplay.

When I add options to the menu
Also might redo the text buttons to just be an invisible square button with text overlayed.

Scan world height in a certain radius (using noise) before choosing the chunk for world spawn and position to spawn in. If a tree or something generates in the way just find a position in the chunk where nothing is in the way, potentially spawning on top thereof.

The ideal spawn is the lowest y value that is above sea level.

Speaking thereof, perhaps players should be a ChunkLoader or something and I should be able to accept multiple. That way potentially adding multiplayer would be easier.

Shader needs render fog to hide my horrible-looking lazy chunkunloading (lazy referring to the technique, not the code. The whole project is full of cursed code no need to emphasise just one bit)

preparation for render vs logic split -> then shared code for client/server can be done

Move it and make it look better. Maybe just decorate the outside of it lol

because the way it works now is cursed and abuses wait() and notifyAll()

E

I can steal some code from my private repo PrankDayGame maybe
Before I update scalpel I want to fix the potential memory leak in it

This will probably the last thing in 2fc0f18, at least in the public "classic" repo

Slight bug with kingdom gui and sometimes with generating paths. Could be:

• related to another issue, so would get solved when I address something else
• related to a problem with chunk gen or chunk storage
• related to a problem in placing the kingdoms

I'm gonna break this somehow, but yeet

How