Ambiera ForumDiscussions, Help and Support. |
|
| [ 1 2 3 ] Page 1 of 3 |
|
|||||
|
For anyone interested in a CopperCube version 7 - this would require rebuilding the source code from the current CopperCube 6 - (Irrlicht 1.6x) to 1.7x which I have tried and its a lot of work actually. I dont think this would ever happen. There are over 500 individual changes that have to be made and cross matched to to all linked files as C++ wont compile if it finds even a single error in syntax or format. The effective difference is mainly small changes - nothing too major as its all still DX9. One thing I found limiting with CopperCube 6 (1.6x) is the setup is limited to shader model 2.0 for writing shaders and hence limits the size and complexity of what you can write. Irrlicht 1.7x can use up to shader mdel 3.0 (max allowed with DX9) and so is better there. For now I will continue peice meal additions as that is far more tolerable and doable. |
||||
|
I believe there are some really low hanging fruits that should not require too much coding, and from that users can benefit much more than from update to the next irrlicht version: * Updating scene tree, so it is easier to change items order * Fix scene tree bug there its elements keep expanding/collapsing randomly if you add/remove or reorder items * Fix issues with game actor - attack cool down time is not calculated properly, so actor "freezes" in case attack animation has too many frames, which is an issue for almost every fbx model * Fix issue with "no clipping" from fps camera is not propagated to not direct children of the core node. Or make it configurable * Add ability to "rotate" 2d nodes (or their content) * Update terrain editor to use some fractal/perlin noise to generate terrain that has a more realistic layout * Add JSON polyfill to spidermonkey initialization the same way as currently vector3d is declared, so it is easier to serialize/deserialize data that way * Fix issues with "no-qwerty" keyboard layouts for default move behaviors * Add keymapping for the existing fps and 3rd person movement behaviors And some other things that are probably more complex: * Add "OnCollission" callback to "Collide When Moved" and collision layers. I believe, currently all world collision is precalculated and it's basically the same layer, so the feature doesn't make sense without having masks * Add crouching behavior * Improve bullet physics so you can also scale physics world compared to the graphical representation you have. Expand more bullet physics stuff to the editor. Like ability to add vehicles nodes for example - which I believe to be a huge request * Update fbx importer for better compatibility with modern modelling/animating software * Add navmesh pathfinding. I guess it also make sense to have separate collision layers for one to be used as navmesh Some of those already has community fixes of course, but it would be really nice to have it from the box. Also some of those requires fixing the editor, which is not possible. Once again, you can make some really good looking games - check Chrisz's or SamGrady's stuff. It's more about functionality limitations of the engine that are sometimes really hard to overcome, at least for me. |
||||
|
Thought it was 3.0 , So are we limited to 512 instructions per fragment program, Robo? (I think that was 2.0) Sam |
||||
|
Hope Copy/Paste action be possible on CC7 
|
||||
|
Hey folks, I wanted to chime in because the OP’s post seems to be spreading a fair bit of misinformation, and it’s showing up in the Announcements section, which really isn’t the right place for this kind of speculative discussion. At first glance, the title made me think CopperCube 7 had just been released — which it hasn’t. That kind of clickbait-y framing isn’t helpful, especially in a section meant for official updates. Let’s break this down point by point with actual facts: --- 1. Irrlicht Version in CopperCube CopperCube does not use Irrlicht 1.6, 1.7, or any version in that range. It runs on a heavily modified fork of Irrlicht 1.5 — this has been confirmed multiple times by Niko (the developer) in forums, documentation, and even in the source code comments of older public builds. So saying “CopperCube needs to be rebuilt to 1.7x” is technically inaccurate and misleading. --- 2. Why irrlicht 1.7x? Why not Stable 1.8.5 or Nightly 1.9? If we’re talking about rebuilding the engine from source of irrlicht (which would be a massive undertaking), then targeting 1.7x makes zero sense. - Irrlicht 1.8.5 is the last stable, officially released version. - Irrlicht 1.9 exists as a nightly/development branch with modern renderer improvements, better shader support, and ongoing community patches. If Niko were to invest the time to modernize the core, jumping to 1.8.5 or even 1.9 would be the logical choice — not some obscure middle-ground like 1.7x. Either the OP doesn’t have full context, or this is just forum rumor escalation. --- 3. Shader Model Confusion The OP claims CopperCube is limited to Shader Model 2.0. That’s flat-out wrong. Go to the official CopperCube shader tutorial page (still live on ambiera.com): > "CopperCube supports Pixel Shader 3.0 and Vertex Shader 3.0 via GLSL and HLSL." There are working examples of normal mapping, specular highlights, parallax, and dynamic lighting — all requiring SM 3.0+. Saying it’s “stuck on 2.0” either means: - The OP never tested modern effects, - Or they’re confusing fallback paths (for ancient GPUs) with the actual capability ceiling. --- 4. Irrlicht vs CopperCube — They Are NOT the Same This is a huge point of confusion in the thread. - Irrlicht = open-source 3D engine (C++, scene graph, rendering, etc.) - CopperCube = closed-source game/editor built on top of a modified Irrlicht 1.5 core You cannot just “port Irrlicht 1.9 code” into CopperCube and expect it to work. The renderer, material system, scene nodes, and extension APIs are all customized. Yes, some concepts carry over — but they’re not interchangeable. The OP mentions successfully porting someone else’s Irrlicht code into CopperCube. That’s impressive technical work, and I genuinely respect the effort. But: - Did they credit the original author? - Are they presenting it as “CopperCube now supports X” when it’s really just a custom extension? That distinction matters. --- 5. AI-Assisted “Vibe Coding” vs Research This feels like a classic case of: > “I saw something cool in Irrlicht ? asked AI how to do it ? pasted code ? assumed it means CopperCube is outdated” That’s not how engine development works. CopperCube’s limitations (and strengths) come from design decisions, not just “old Irrlicht”. Blaming the engine without understanding why certain paths were chosen leads to threads like this — full of passion, light on accuracy. --- Final Thoughts - This should be in General Discussion, not Announcements. - The thread title is misleading. - Several claims are factually incorrect (Irrlicht version, shader model, upgrade path). - Porting work is [b]val |
||||
|
- Porting work is valuable, but let’s give credit and context. - If we want CopperCube 7 to happen, constructive, informed feedback helps way more than speculation. I’m all for pushing the engine forward — I’ve done my share of extensions and hacks too. But let’s base the conversation on what’s real, not forum vibes. Thanks for reading. Let’s keep the discussion technical, accurate, and in the right section. Cheers! |
||||
|
the editor is the problem not the engine, goof |
||||
|
anyway, robbo, i wish you'd spend your time making your own editor and move on from this mess... you've spent entirely too much time trying to be fix niko's codebase so why would he even bother doing it... i told you dummies this blackbox crap was going to give him an out. you'd probably even have more fun making buttons in your own editor then this... hell look at this project called easy fps editor on itch. you can do that now, vibe-coding be damned, so give it a shot. i think its time to move on. no offense. |
||||
|
THE. EDITOR CODE. SUCKS. ASS.  *sowwies* |
||||
|
Damn and i made all this from scratch? 
|
||||
|
Guest, i totally don't agree with you, it's high time you people stop treating this engine like shi*, this engine is capable, if you can't contribute don't discourage others, move on if you don't like it, you haven't been forced, have you? |
||||
|
@chrisz look at the bonkers numbering of the trees in your project, bro. that's the editor being wonky as heck. pinie11111111110!? wtf. @sikes contribute to what exactly? no one has access to the editor code, brainiac. it sucks. in the big boy world people have differing opinions. deal with it. |
||||
|
What numbering trees. Did you do a reverse hack on my game  Why? Btw the number is not relevant. The game is 24 MB - and it es bigger than the most 2 GB Games showing in this board 
|
||||
|
The problem is that the most "User Developer" have no clue what is happening in making games. The Editor is not bad. And Copper Cube is not bad at all. I'm happy that this engine exists. Its easy. |
||||
|
Yes, I know the original codebase was taken from 1.5 - but new stuff has been added over time by Niko so its not 1.5 anymore is it ? I did see a note somewhere that shows the updates as taken from 1.6 - not 1.5 so thats why I expect Niko calls it CopperCube 6 as against CopprCube 5 previously and also answers the question many have had in the past about so called CopperCube 7 as I mentioned wont happen as its too much work - even for me so definately too much time for Niko to do as anything more than like 1 hour per year seems too much for him these days. And no, I never said it had to be updated to Irrlicht 1.7 as like I said before - its mostly small adjustments anyway but small changed can and do add up to better functionality. If I want to update an old engine that my perogative - if you dont like people fixing things up then get out of the way and stop being an obstacle and yes, almost every other game engine out there today is far superior to CopperCube in almost everyway unless its still incomplete. Lots of cancelled engines better than CopperCube has ended years ago and now open source as fixed up by the community instead which frankly Niko should make the Editor open source as its getting ridiculous his death grip on keeping the source code to himself as he tries to exact out the last cent from it... Yes, I agree the Editor code needs serious fixing up and could and would have been done by myself and others if available. Then the community and the engine would really be so much better so I hope he does just that. |
||||
| [ 1 2 3 ] Page 1 of 3 |
|
|
){kind=link}