Tags
Creators
Details
Licensed LGPL-3.0-only
Published 3 years ago
Updated 2 months ago
All versions
3.0.0
Release
3.0.02 years ago 213.3K
Compatibility
Minecraft: Java Edition
1.21–1.21.1
1.20.6
1.20.4
1.20.1–1.20.2
1.19.4
1.19.2
1.18.2
1.17.1
1.16.5
Platforms
Fabric
Forge
NeoForge
Supported environments
Client-side
Server-side
Client and server
Changes
Highlights:
- Due to breaking changes (mainly caused by incorrectly named objects) the api version number has been up from 2.1.0 to 3.0.0
- please make sure your implementing programs check the API version and handle old DH versions cleanly.
Full Details:
updated javadocs
Additions:
- Generic Rendering API
- New objects include:
- DhApiRenderableBoxGroupShading
- DhApiRenderableBox
- DhApiBeforeGenericRenderSetupEvent
- DhApiBeforeGenericRenderCleanupEvent
- DhApiBeforeGenericObjectRenderEvent
- IDhApiRenderableBoxGroup
- IDhApiCustomRenderRegister
- IDhApiCustomRenderObjectFactory
- IDhApiGenericObjectShaderProgram
- IDhApiGenericRenderingConfig
- New bindings/methods include:
- DhApi.Delayed.IDhApiCustomRenderObjectFactory
- IDhApiLevelWrapper.getRenderRegister()
- IDhApiGraphicsConfig.IDhApiGenericRenderingConfig
- New objects include:
- Optional memory caching to IDhApiTerrainDataRepo methods
- This allows for much faster raycasting and repeat query operations
- IDhApiTerrainDataCache
- New Enum EDhApiBlockMaterial
- New getter IDhApiBlockStateWrapper methods
- IDhApiBlockStateWrapper.getSerialString()
- IDhApiBlockStateWrapper.getMaterialId()
- New wrapper Factory methods to builder wrappers from resource location strings (IE "minecraft:stone", or "minecraft:plains")
- IDhApiWrapperFactory.getBiomeWrapper(String resourceLocationString, IDhApiLevelWrapper levelWrapper)
- IDhApiWrapperFactory.getDefaultBlockStateWrapper(String resourceLocationString, IDhApiLevelWrapper levelWrapper)
- Optional additional world gen DhApiChunk validation
Bugfixes:
- Fix/add AbstractDhApiChunkWorldGenerator.generateApiChunk()
- API Chunk generation was present previously but was broken preventing it's correct use
Breaking Changes:
-
Renamed
- Math/Position objects
- Vec3f -> DhApiVec3f
- Vec3d -> DhApiVec3d
- Vec3i -> DhApiVec3i
- Mat4f -> DhApiMat4f
- Affected API objects:
- Vec3i -> DhApiVec3i
- DhApiRaycastResult
- DhApiBeforeBufferRenderEvent
- DhApiAfterRenderEvent
- IDhApiShaderProgram
- IDhApiCullingFrustum
- Mat4f -> DhApiMat4f
- DhApiRenderParam
- Vec3i -> DhApiVec3i
- Math/Position objects
-
Removed
- IDhApiGpuBuffersConfig
- These config values didn't need to be changed by the end users (Note: if James is wrong and these do need to be changed in some edge cases, let him know so the change can be rolled back)
- this includes:
- gpuUploadMethod
- gpuUploadPerMegabyteInMilliseconds
- IDhApiGpuBuffersConfig
Deprecations:
- IDhApiLevelWrapper.getHeight()
- This change is done so get min/max heigth are both viable methods
- use getMaxHeight() instead
- DhApiChunk constructor
- This change was due to the old constructor's parameters being in the wrong order (Specifically top and bottom positions being flipped)
- use DhApiChunk.create() instead
- DhApiTerrainDataPoint constructor
- This change was due to the old constructor's parameters being in the wrong order (Specifically top and bottom positions being flipped)
- use DhApiTerrainDataPoint.create() instead
- EDhApiGpuUploadMethod.BUFFER_MAPPING
- Buffer mapping was removed as an option due to memory leaks in the old system and having one system being simpler. This can be reverted if users determine that buffer mapping is better in some situations.
- IDhApiWorldGenerator.isBusy()
- The method now has a default implementation but isn't used.
- The task queuing logic is now handled internally by DH
Supplementary resources
| File | Type | Size | |
|---|---|---|---|
| DistantHorizonsApi-3.0.0.jar | Unknown | 283.81 KiB |
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:Xs0XTOVv:1uUP7LpX"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:Xs0XTOVv:1uUP7LpX"
}

