This was just an example, the full version would be more like:
int renderType = MinecraftForgeClient.getBlockRenderType(blockId, pass, ...)
if(renderType == ...)
the return value defines how the rendering should proceed: not now, single render, multi-render, etc.
Calling a static method is easy to organize with reflection and it means no need to distribute different versions.
The complex logic should be hidden in the MinecraftForge classes and only the call should be in the render class. This will minimize the impact and make merging easier.
The point was to allow the decision to be made per-block, not just by block ID, although I'm starting to follow now.
A better way to handle the infinite terrain textures would be to expand the base texture to be 32x32 icons for example and use scaled coordinates to render. This will require changing some base classes like RenderBlocks and ItemRenderer. The mods can get the texture index dimensions from MinecraftForgeClient and render with scaled coordinates if they need to. The idea is to avoid the texture switches, they are quite expensive.
An even better way, that works in more cases, would be to create multiple Tessellators, one for each texture in the solid object pass. That takes out the texture switches without imposing the limitations that simply expanding the main texture file imposes. If it wasn't such a big change to the code, I'd be pushing for it myself. There's no way that RedPower will work with anything but its own texture pages - and since it currently uses 288 terrain sprites, it would still use over a quarter of the sprites on the 32x32 icon texture.
EDIT: Make that 320 terrain sprites, as of 1.6.0.
EDIT2: You know... I wonder. I might be able to make that happen. I'll have to think about it.
EDIT3: I'm definitely going to be investigating that in the future. It would take all the performance hit out of the texture code.
The point was to allow the decision to be made per-block, not just by block ID, although I'm starting to follow now.
An even better way, that works in more cases, would be to create multiple Tessellators, one for each texture in the solid object pass. That takes out the texture switches without imposing the limitations that simply expanding the main texture file imposes. If it wasn't such a big change to the code, I'd be pushing for it myself. There's no way that RedPower will work with anything but its own texture pages - and since it currently uses 288 terrain sprites, it would still use over a quarter of the sprites on the 32x32 icon texture.
EDIT: Make that 320 terrain sprites, as of 1.6.0.
Yes, i would just like to remove the MCForge specific logic from the central classes, one-liner with return value and interpretation is fine.
Expanding the Tessellator to support one instance per texture is not that hard. I was considering this in order to make Full Screen Antialiasing and Anisotropic Filtering to work correctly. The idea was to split the terrain.png in 256 textures and the Tessellator to render them with one instance per texture, quite similar. This minimizes the texture switches, but does not eliminate them. There are still several texture switches per rendered WorldRenderer.
I could make a Tessellator that uses one instance per texture if this would help.
After the last post, I've tried to play around a little with ITextureProvider, but my code doesn't seem to work on items (they work perfectly fine on blocks though!)...
do I have to do something special in the mod_XXX class when I create the item?
the item code I have now in the mod_xxx constructor:
arcanaCard=(new Item(arcanaCardID)).setItemName("arcanaCard")..setIconCoord(0, 0);
ModLoader.AddName(arcanaCard, "The Fool");
and here's the ItemarcanaCard class:
package net.minecraft.src.Persona;
import net.minecraft.src.*;
import net.minecraft.src.forge.*;
public class ItemarcanaCard extends Item
implements ITextureProvider
{
protected ItemarcanaCard(int i) {
super(i);
}
// using the custom item.png file instead of the default.
public String getTextureFile() {
return mod_Persona.textureRES;
}
}
After the last post, I've tried to play around a little with ITextureProvider, but my code doesn't seem to work on items (they work perfectly fine on blocks though!)...
do I have to do something special in the mod_XXX class when I create the item?
You sure do! Try creating an ItemarcanaCard instead of an Item! :smile.gif:
I'm not getting how to install the latest minecraft forge. :/
It's, uh, the same as any other mod that has to override base classes.
Because you already have to have installed ModLoader (identical installation instructions, with different files) to have any use for Forge, it's assumed you know how that works already (which you should...).
A m8 was suggesting this as something that might make a larger draw for MiencraftForge.
Disclaimer: We already know that the team does not want to actually integrate things into MCF in order to keep it slim.
However we wondered that if some of the basic optimization from Optifine could be injected straight into MCF Client. Then for the community there is a draw that even if you don't do anything else with it, MCF still helps with game optimization.
And when we say basic optimization we mean the bare bones. All of the beautiful stuff that SP614X writes can and should still be a separate mod that is built on top of it (provided SP wants to hop in. Pretty pretty please *puppy dog eyes*)
Anyways just an idea in passing. As always feel free to blow off :smile.gif:
A m8 was suggesting this as something that might make a larger draw for MiencraftForge.
Disclaimer: We already know that the team does not want to actually integrate things into MCF in order to keep it slim.
However we wondered that if some of the basic optimization from Optifine could be injected straight into MCF Client. Then for the community there is a draw that even if you don't do anything else with it, MCF still helps with game optimization.
And when we say basic optimization we mean the bare bones. All of the beautiful stuff that SP614X writes can and should still be a separate mod that is built on top of it (provided SP wants to hop in. Pretty pretty please *puppy dog eyes*)
Anyways just an idea in passing. As always feel free to blow off :smile.gif:
This really isn't intended as a client mod man. It's an API for mod developers which players will likely never have to even install (since it will be packaged with the individual mods that use it).
That type of feature is better suited to a mod, not an API.
True, hence the stipulation of putting it in the client MCF rather than some other place, but the point is taken.
Quote from FlowerChild »
It's an API for mod developers which players will likely never have to even install (since it will be packaged with the individual mods that use it).
I was under the impression that it was a single client release and a source/modders API at any given time. Otherwise it is kind of pointless, and I want to wash my mouth out just for saying that.
If the point is to add base hooks so that modders don't have to edit the base files, but they are all changing the base classes to add their own hooks anyways, how is that any different from before? If that is the case you are still going to have a couple dozen modders that all have their own subversion of MCF that is likely going to conflict with another subversion of MCF because they edit the same base class to add a hook.
The brilliance was that they were going to add the hook needed into the MCF package, and then push that as a new version so that everything using it does not alter base classes.
Unless there are hooks for hooks? I suppose I am not wrapping my head around the logic of multiple people being able to add a hook to a base class on separate copies of MCF from each other and there not be a conflict without some sort of merging.
True, hence the stipulation of putting it in the client MCF rather than some other place, but the point is taken.
I was under the impression that it was a single client release and a source/modders API at any given time. Otherwise it is kind of pointless, and I want to wash my mouth out just for saying that.
If the point is to add base hooks so that modders don't have to edit the base files, but they are all changing the base classes to add their own hooks anyways, how is that any different from before? If that is the case you are still going to have a couple dozen modders that all have their own subversion of MCF that is likely going to conflict with another subversion of MCF because they edit the same base class to add a hook.
The brilliance was that they were going to add the hook needed into the MCF package, and then push that as a new version so that everything using it does not alter base classes.
Unless there are hooks for hooks? I suppose I am not wrapping my head around the logic of multiple people being able to add a hook to a base class on separate copies of MCF from each other and there not be a conflict without some sort of merging.
The idea is no different from something like ModLoader, EXCEPT you are allowed to redistribute the obfuscated files for this API along with your mod so that players don't have to download it separately.
If you want additional hooks for your mod, ideally you don't make them to your own copy of the base class files, rather you get the hooks added to the API (which everyone shares) so that you don't have to.
The idea is no different from something like ModLoader, EXCEPT you are allowed to redistribute the obfuscated files for this API along with your mod so that players don't have to download it separately.
I'd like to know where you got this idea that they're meant to redistribute it -- does it make more sense to force your users to clutter up their JAR with all of these base-unclean mods because of integrated MCF, or just install MCF once and be able to put the then base-clean mod.zip in the /mods/ folder without modifying the JAR again?
The OP states that you're ALLOWED to do so, not that you're MEANT to.
Yes, those mean two very different things.
Ok I may have started something here that I did not mean to so lets take a step back and cool off a second before we all start smacking each other going "No it means this! Fool!" Whereupon one of us gets whacked with the cane and Excalibur is dancing again.
Spacetoad? Eloraam? Can you please clarify for us? I think it actually does make a difference. If it is a single release it reduces mod clutter a ton! If it is internal mod packages then I am a bit concerned with long term internal compatibility.
edit: I don't want this thread to turn into people arguing over things a lot. Discussion, fine. Arguing, please don't. This thread must be perfect! *starts rocking back and forth* yes...yes...perfect....
I think i get it, basically minecraft forge will be packed with downloads people get but those downloads may only pertain to what a particle mod needs, and if you have more then 1 mod that needs minecraft forge, you can come here to download the main package? is this correct... or am i completely off guard here?
I'd like to know where you got this idea that they're meant to redistribute it -- does it make more sense to force your users to clutter up their JAR with all of these base-unclean mods because of integrated MCF, or just install MCF once and be able to put the then base-clean mod.zip in the /mods/ folder without modifying the JAR again?
The OP states that you're ALLOWED to do so, not that you're MEANT to.
Yes, those mean two very different things.
Ummm...dude, whether a mod includes the base-class modifications that are part of the API, or whether the player downloads those base-class modifications themselves, the end result is the same: their copy of Minecraft is modified to contain the base-class modifications.
No difference whatsoever, so not sure where your concern is. Sure, if a particular mod-author doesn't want to distribute the API as part of his mod, he doesn't have to. But personally, I see no reason why someone wouldn't save their players the extra download step by simply including the API in their own download.
EDIT: And yes, of course if you are committed to having a totally base-class- mod-free download so that you're whole mod can be dropped into the /mods folder in a .zip file, then you can direct your players here to download the API themselves. Personally, the mod I work on is so extensive, that being base-clean will likely never be an option (no matter how many hooks I have access to), so it's not something I will personally be doing, and I will simply be packaging the API along with Better Than Wolves to save my players that extra download step.
Either option is perfectly valid. Think of it like DirectX. You can go to Microsoft's site and download it for yourself, but most games that you purchase retail will include it on the disk for ease of installation.
Spacetoad? Eloraam? Can you please clarify for us? I think it actually does make a difference. If it is a single release it reduces mod clutter a ton! If it is internal mod packages then I am a bit concerned with long term internal compatibility.
edit: I don't want this thread to turn into people arguing over things a lot. Discussion, fine. Arguing, please don't. This thread must be perfect! *starts rocking back and forth* yes...yes...perfect....
The idea is that it can be used either way. For large content mods like BTW, it's possible to include the Forge source directly.
Personally, I plan to do a direct deep link in my download links for RedPower, so it'll say "download MinecraftForge here". SpaceToad seems to be linking users to this page instead.
That's the nice thing about this API set - we don't all have to do it the same way.
Also, as far as I understand it, it's entirely possible to do BOTH - mods that bundle MinecraftForge may still function if installed as a zip, if the user has installed MinecraftForge, assuming that mod is otherwise base-clean.
I am interested in this.. however I made note of something said in early forum about difficulty installing on windows? And also SpaceToad makes mention of an Eclipse setup? I prefer my work in MCP, it's just easier on the eyes and frankly, I fail at setting up my Eclipse, thus far.
I would like to commit to using this for some of my users, they seem to be running out of Sprite indices and Smith_61 has taken an indefinite hiatus with a rather inconvenient bug in his 7.07 version of MCE.
I was considering, at lengths, switching to Scokeev's Sprite API about a week ago and someone on my thread told me to look into this. It sounds very promising.
So er.. in summary, I suppose my two questions are.. how hard is this to install and can it make use of MCP? (or vice versa)
I am interested in this.. however I made note of something said in early forum about difficulty installing on windows? And also SpaceToad makes mention of an Eclipse setup? I prefer my work in MCP, it's just easier on the eyes and frankly, I fail at setting up my Eclipse, thus far.
I would like to commit to using this for some of my users, they seem to be running out of Sprite indices and Smith_61 has taken an indefinite hiatus with a rather inconvenient bug in his 7.07 version of MCE.
I was considering, at lengths, switching to Scokeev's Sprite API about a week ago and someone on my thread told me to look into this. It sounds very promising.
So er.. in summary, I suppose my two questions are.. how hard is this to install and can it make use of MCP? (or vice versa)
Hello there.
Despite being a Linux user myself, I spent a considerable portion of tonight working on the Windows installation. It's getting a lot closer to being easy to use. Right now, the easiest way is to do an SVN pull (either downloading directly from SourceForge or using an SVN client (I think TortoiseSVN was mentioned for Windows users?)). Once you have that, just move the directory from the pull into a 'forge' subdirectory of your mcp folder, and run the setup.bat file.
It's intended to be installed with MCP, so that part isn't a problem.
We know it's currently still a little bit of a problem and we're hoping to make it a lot easier in the next couple days. I'm hoping we'll get it boiled down to a simple "unzip into mcp and run the bat" installation procedure soon.
The point was to allow the decision to be made per-block, not just by block ID, although I'm starting to follow now.
An even better way, that works in more cases, would be to create multiple Tessellators, one for each texture in the solid object pass. That takes out the texture switches without imposing the limitations that simply expanding the main texture file imposes. If it wasn't such a big change to the code, I'd be pushing for it myself. There's no way that RedPower will work with anything but its own texture pages - and since it currently uses 288 terrain sprites, it would still use over a quarter of the sprites on the 32x32 icon texture.
EDIT: Make that 320 terrain sprites, as of 1.6.0.
EDIT2: You know... I wonder. I might be able to make that happen. I'll have to think about it.
EDIT3: I'm definitely going to be investigating that in the future. It would take all the performance hit out of the texture code.
Yes, i would just like to remove the MCForge specific logic from the central classes, one-liner with return value and interpretation is fine.
Expanding the Tessellator to support one instance per texture is not that hard. I was considering this in order to make Full Screen Antialiasing and Anisotropic Filtering to work correctly. The idea was to split the terrain.png in 256 textures and the Tessellator to render them with one instance per texture, quite similar. This minimizes the texture switches, but does not eliminate them. There are still several texture switches per rendered WorldRenderer.
I could make a Tessellator that uses one instance per texture if this would help.
do I have to do something special in the mod_XXX class when I create the item?
the item code I have now in the mod_xxx constructor:
and here's the ItemarcanaCard class:
You sure do! Try creating an ItemarcanaCard instead of an Item! :smile.gif:
ahhhh!! I see what's wrong now! Face drumming on my desk...
Thank you a lot!!!
It's, uh, the same as any other mod that has to override base classes.
Because you already have to have installed ModLoader (identical installation instructions, with different files) to have any use for Forge, it's assumed you know how that works already (which you should...).
Disclaimer: We already know that the team does not want to actually integrate things into MCF in order to keep it slim.
However we wondered that if some of the basic optimization from Optifine could be injected straight into MCF Client. Then for the community there is a draw that even if you don't do anything else with it, MCF still helps with game optimization.
And when we say basic optimization we mean the bare bones. All of the beautiful stuff that SP614X writes can and should still be a separate mod that is built on top of it (provided SP wants to hop in. Pretty pretty please *puppy dog eyes*)
Anyways just an idea in passing. As always feel free to blow off :smile.gif:
This really isn't intended as a client mod man. It's an API for mod developers which players will likely never have to even install (since it will be packaged with the individual mods that use it).
That type of feature is better suited to a mod, not an API.
I was under the impression that it was a single client release and a source/modders API at any given time. Otherwise it is kind of pointless, and I want to wash my mouth out just for saying that.
If the point is to add base hooks so that modders don't have to edit the base files, but they are all changing the base classes to add their own hooks anyways, how is that any different from before? If that is the case you are still going to have a couple dozen modders that all have their own subversion of MCF that is likely going to conflict with another subversion of MCF because they edit the same base class to add a hook.
The brilliance was that they were going to add the hook needed into the MCF package, and then push that as a new version so that everything using it does not alter base classes.
Unless there are hooks for hooks? I suppose I am not wrapping my head around the logic of multiple people being able to add a hook to a base class on separate copies of MCF from each other and there not be a conflict without some sort of merging.
The idea is no different from something like ModLoader, EXCEPT you are allowed to redistribute the obfuscated files for this API along with your mod so that players don't have to download it separately.
If you want additional hooks for your mod, ideally you don't make them to your own copy of the base class files, rather you get the hooks added to the API (which everyone shares) so that you don't have to.
I'd like to know where you got this idea that they're meant to redistribute it -- does it make more sense to force your users to clutter up their JAR with all of these base-unclean mods because of integrated MCF, or just install MCF once and be able to put the then base-clean mod.zip in the /mods/ folder without modifying the JAR again?
The OP states that you're ALLOWED to do so, not that you're MEANT to.
Yes, those mean two very different things.
Spacetoad? Eloraam? Can you please clarify for us? I think it actually does make a difference. If it is a single release it reduces mod clutter a ton! If it is internal mod packages then I am a bit concerned with long term internal compatibility.
edit: I don't want this thread to turn into people arguing over things a lot. Discussion, fine. Arguing, please don't. This thread must be perfect! *starts rocking back and forth* yes...yes...perfect....
Ummm...dude, whether a mod includes the base-class modifications that are part of the API, or whether the player downloads those base-class modifications themselves, the end result is the same: their copy of Minecraft is modified to contain the base-class modifications.
No difference whatsoever, so not sure where your concern is. Sure, if a particular mod-author doesn't want to distribute the API as part of his mod, he doesn't have to. But personally, I see no reason why someone wouldn't save their players the extra download step by simply including the API in their own download.
EDIT: And yes, of course if you are committed to having a totally base-class- mod-free download so that you're whole mod can be dropped into the /mods folder in a .zip file, then you can direct your players here to download the API themselves. Personally, the mod I work on is so extensive, that being base-clean will likely never be an option (no matter how many hooks I have access to), so it's not something I will personally be doing, and I will simply be packaging the API along with Better Than Wolves to save my players that extra download step.
Either option is perfectly valid. Think of it like DirectX. You can go to Microsoft's site and download it for yourself, but most games that you purchase retail will include it on the disk for ease of installation.
The idea is that it can be used either way. For large content mods like BTW, it's possible to include the Forge source directly.
Personally, I plan to do a direct deep link in my download links for RedPower, so it'll say "download MinecraftForge here". SpaceToad seems to be linking users to this page instead.
That's the nice thing about this API set - we don't all have to do it the same way.
Also, as far as I understand it, it's entirely possible to do BOTH - mods that bundle MinecraftForge may still function if installed as a zip, if the user has installed MinecraftForge, assuming that mod is otherwise base-clean.
I would like to commit to using this for some of my users, they seem to be running out of Sprite indices and Smith_61 has taken an indefinite hiatus with a rather inconvenient bug in his 7.07 version of MCE.
I was considering, at lengths, switching to Scokeev's Sprite API about a week ago and someone on my thread told me to look into this. It sounds very promising.
So er.. in summary, I suppose my two questions are.. how hard is this to install and can it make use of MCP? (or vice versa)
Hello there.
Despite being a Linux user myself, I spent a considerable portion of tonight working on the Windows installation. It's getting a lot closer to being easy to use. Right now, the easiest way is to do an SVN pull (either downloading directly from SourceForge or using an SVN client (I think TortoiseSVN was mentioned for Windows users?)). Once you have that, just move the directory from the pull into a 'forge' subdirectory of your mcp folder, and run the setup.bat file.
It's intended to be installed with MCP, so that part isn't a problem.
We know it's currently still a little bit of a problem and we're hoping to make it a lot easier in the next couple days. I'm hoping we'll get it boiled down to a simple "unzip into mcp and run the bat" installation procedure soon.