Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Jan 26, 2013 12:15 am Post subject:
I'll be honest and tell you: I can't trust in the combination of .NET and GPL. I know Mono guys are doing a great job with porting .NET onto Linux but I can't trust in any framework being a good solution when it comes to Linux, because those mostly needs a reimplementation, especially when it's a Microsoft one.
You guys did a great job with OpenRA but you can't assure performance since Mono does ebverything differently than .NET in engine level.
Call me Stallman, but I'd either go C++ or D if I would do that. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Ooooh, programming language advocacy. This thread has evolved alright.
Frankly, I don't see the connection you're making, Graion. GPL does not mean "guaranteed to run on Linux", it's a Free Software license. It allows you to beat it into shape to run on Mono, if you wish. It doesn't force you to, and it doesn't encourage you to. In fact, the GPL states clearly
GPL wrote:
THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
So yeah. Really not seeing the issue you have with someone writing free .NET software.
@Matthias M.: Have you guys considered packaging the fundamental functions like reading the game formats into a library? _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Jan 26, 2013 4:21 pm Post subject:
I don't have issues with writing free NET software, be it BSD, MIT or any CC. But writing GPL software when the patents under that are not certainly to be compatible with GPL everytime is an issue IMO.
Microsoft can declare Mono breaching their patents whenever they want and that's totally against the GPL spirit. Java is a bit better because at there Oracle will make certain that there will be a version on the Linux, but that's only just a bit better.
GPL makes sure that the code is useable by the public... throwing out an OS makes the code unusable for that OS entirely, so yeah, there goes the general public part of the license. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
What do the potential patent issues in Mono have to do with developing free .NET software?
After the fifth read, I am assuming you're having an ethical/moral issue with this, based on the idea that GPL'd software should work everywhere, easily, equally, and that's not guaranteed for the .NET environment...
...can't say anything but "I disagree, and that's not what the license says" to that. _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Jan 26, 2013 7:31 pm Post subject:
Your assumption is correct, after all, and yes, it's a moral issue of mine. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
The OpenRA engine only uses parts of the ECMA standardized C# language and CLI framework. The rest is https://github.com/mono/tao for SDL and OpenGL calls https://github.com/icsharpcode/SharpZipLib for handling .zip files. Only the map editor uses WinForms and we think of replacing this because of usability problems with the GUI and redundancy. The OpenRA project is not affected by any Microsoft patents. Your concerns are unwarranted. You can contribute to http://openredalert.googlecode.com/ in C++ or https://github.com/ultraq/redhorizon in Java if you want to reinvent it in your favorite language. I like our current approach as the code is beginner friendly and I don't need to install a virtual machine that comes with adware crap by default now thanks to Oracle. The language design of C# also eases some parts required for this project like vector math.
Renegade wrote:
@Matthias M.: Have you guys considered packaging the fundamental functions like reading the game formats into a library?
Nice. Did I gather correctly from previous comments that the file format support ends with RA, essentially? (No TS/RA2 support?) _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Feb 23, 2013 5:27 pm Post subject:
If that is the future... that is not my future.
Good job, tho. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Yeah it's very nice for people who want to port TS/RA2/YR etc to that engine but if you've got full SHP or 2D support then voxels are essentially useless.
Personally I'd so rather see a new game being developed on OpenRA rather than porting the old ones since the old ones are perfectly fine and I'd rather play those. QUICK_EDIT
Yeah it's very nice for people who want to port TS/RA2/YR etc to that engine but if you've got full SHP or 2D support then voxels are essentially useless.
Personally I'd so rather see a new game being developed on OpenRA rather than porting the old ones since the old ones are perfectly fine and I'd rather play those.
This. I said it, but sadly this became a priority.
But then, what's left is transition to RA palette format, and entire mods can be ported later. QUICK_EDIT
wow those voxel look impressive. i'm sure they will include vpl in the future. [but truely what a point to use voxel if they can go to use real 3d that a lot more flexible but however...]
only thing i hate on OpenRa is their game slow as hell and 1 second response command make it even worse.
if some one help me about coding I'm glad to make new original game for Open Ra.
Regarding our previous exchange, I am interested in getting a bit deeper into this and maybe helping out with some YR extensions, but I'm about to move (physically, IRL), so I'm a bit occupied atm.
Maybe I'll just send you a pull request out of nowhere someday. _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Feb 24, 2013 8:35 pm Post subject:
Based on what I see in YR++... I honestly doubt that one. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Tue Feb 26, 2013 6:07 am Post subject:
Yep. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Well I'm quite certain I mentioned this before, ages ago, and people seemed to agree with me on that point. So how about now, does anyone agree with me here? QUICK_EDIT
Well, pd, Alex, D and half a dozen others have looked at the game's code again and again for years now, and I don't remember anyone ever mentioning anything that suggested the voxels aren't used directly as they are.
I don't remember seeing anything in YR++ suggesting that, either.
Frankly, I don't see the point, either - they were already using SHPs for infantry and had systems in place to do the same for vehicles, so why implement quasi-3D-support, ship dozens of 3D models, only to then render 2D-content on the fly?
An optimization would be caching the voxel's rendered image for each kind of rotation that ever occurs (ie once a new rotation occurs, cache that). Saves all the lighting and normal calculations that have to be done (I suppose).
I don't think the game does that by default, at least I can't remember seeing any of that. Honestly though, I've never been that deep into voxel rendering that I could tell for sure right now, but I agree with Ren that somebody should have noticed that. QUICK_EDIT
if you look at the game vxls via xcc mixer, isn't it basically showing a sprite? _________________
The enemy shall be injected with toxic poison - Venom QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Tue Feb 26, 2013 7:16 pm Post subject:
Those are renders, not sprites. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Well, I'm sticking to what I said. I'm surprised it didn't occur to you guys that this is what was going on. I very faintly think that, sometime before Tiberian Sun was released, Westwood Studios said that the voxels were cached to sprites. I cannot find that information again though.
This lossy optimisation doesn't have to apply to just voxels either; it could also apply if they had chosen to use textured polygons instead and I suggest perhaps OpenRA do that. QUICK_EDIT
I have no idea what OpenRA is based on, but if it's any kind of modern rendering engine (I hope they use OpenGL), then caching textured polygons into sprites would be a waste of VRAM, as drawing the textured polygon directly is as fast (because sprites are textured polygons).
Concerning voxels, it may still be a good idea.
Just by the way, why is this in the "Ares is dead" thread? QUICK_EDIT
It is in the "Ares is dead" thread because if the community can build their own game engine from scratch then they wouldn't need to edit a pre-existing engine via hacking, which I assume is extremely technically difficult and also has potential legal and moral problems.
Sprites can use textured polygons but they don't have to; they can use another method which is a lossy optimisation which was probably used by the original games. However, even if they were textured polygons, they wouldn't draw at the same speed as proper 3d model textured polygons. QUICK_EDIT
Most likely yes.
Isometric, half-3d terrain, vxl support, and other aspects are a whole new level. Except the OpenRA devs considered this when they started the project and thus use already data structures with 3d support, while using now only the 2d components for RA. But isometric terrain is also quite different to the rectangle-tile layout of the classic C&Cs _________________ SHP Artist of Twisted Insurrection: Nod buildings
Sprites can use textured polygons but they don't have to; they can use another method which is a lossy optimisation which was probably used by the original games. However, even if they were textured polygons, they wouldn't draw at the same speed as proper 3d model textured polygons.
In 3D renderers like OpenGL, "sprites" do not exist. In that case, "sprite" is a synonym for a quad (= 4-gon) with a texture. A "proper 3D model" is a set of textured triangles. So how would drawing two textured triangles (a quad, or "sprite") be any slower?
The original games did not use any 3D renderer, they used software blitting, sprites are bitmaps in that scenario. They are not (and cannot be, without complicating blitting so much it becomes even slower) compressed, unless you want to consider RLE (as used in various SHP variants) a compression. I'm also not sure why you keep refering to "lossy" compressions, that doesn't make any sense at all in this context.
I can imagine that Westwood pre-rendered voxels into sprites, but as mentioned, I'm not sure about that. It might definitely speed things up and OpenRA should do it. QUICK_EDIT
pd, it seems we are confusing each other because when we say textured polygons we could be referring to proper 3d textured many triangle models or just flat pictures represented using 2 triangles in rectangle formation (quads). I'm sure we both agree blitting is the fastest, then next fastest is quads, and then slowest are voxels and proper 3d textured many triangle models. I was guessing that OpenRA was using the slowest method and was suffering badly because of it so I was trying to help by pointing out an alternate method which is much faster but not as good in quality and accuracy. I was also suggesting that perhaps voxels should be ditched in favour of proper 3d textured many triangle models.
I didn't mean lossy compression as in using less data and memory. I meant using less processing power while also losing some quality and accuracy. Perhaps there is better terminology for that but I don't know it currently. QUICK_EDIT
Yep, that's what lossy compression means. Blitting is copying pixels (or more generally, bytes) from one place to another directly. They have to be raw so the video driver can display them. If you have to pipe them through a decompressor, it makes blitting even slower than it already is.
Quote:
I'm sure we both agree blitting is the fastest, then next fastest is quads, and then slowest are voxels and proper 3d textured many triangle models.
Nope.
Blitting is probably the slower kind of drawing operation on a large scale, which is why it has been abandoned widely in games and most 2D games these days are created in a 3D space with an orthographic view. 3D renderers can render a quad for as good as free (in presence of proper hardware and compared to blitting at least), what takes most time in a GPU concerning that is swapping textures.
I'm not sure if voxels and triangle models can be compared, unless you see them as Minecraft-like block models. In either case, they are probably slow as hell to render (unless there is explicit hardware support which seems to be in development).
What we can definitely agree on, I believe, is that whatever OpenRA uses blitting or 3D, they should pre-render voxels. QUICK_EDIT
When I was talking about the speed I was making an assumption that all processors are heading towards being RISC instead of CISC, meaning no more specialised hardware and no more complex operations for free. If that assumption is correct then what I said about the speed of the different methods is correct, no? QUICK_EDIT
3D is done on the GPU, not the CPU. Those days are past. I have honestly no idea what models GPUs are these days, but they are horribly fast in what they're doing - and dedicated to it.
Blitting is usually a simple copy operation of pixel data (whatever format, 5R6G5B in YR and TS) from one place in memory a back that's uploaded to the video RAM every frame so it can be displayed. It was safe to use it when resolutions were low, but the more you blit the slower it gets (640x480 was 307,200 pixels, 1280x1024 would already be four times as much, that's assuming we're just filling the screen with pixels, usually things are a lot more complicated). Features like alpha blending and depth checks additionally complicate it and make it slower. Uploading stuff to the video RAM also takes an awful while. The thing is that this is all done in the same time window as game logics and possibly networking (I'm not sure if networking was multi-threaded in YR and prior). So on a large scale, blitting becomes slow, not because it's a slow operation in itself, but because of the overhead it generates and the time it takes away from other things.
3D saves that CPU and memory load and operates almost solely on the GPU. All you upload to it are textures (usually once, before you draw anything, e.g. in a loading screen) and from that point on, it's mostly just commands (e.g. render that quad with that texture at that place), which are passed as good as instantly. The GPU takes care of actually rendering and displaying things whenever it's ready, so the main program flow is not interrupted.
I can't honestly tell whether a textured quad is rendered a lot faster by the GPU than blitting a sprite of the same proportions etc. is using CPU and RAM. Of course, that also depends a lot on the hardware involved. But the key is that the GPU is dedicated to doing its 3D stuff and can do it on its terms, while the CPU and RAM are being left alone of sorts and can take care of whatever else needs to be done (game logics). That's what I mean by 3D is faster than blitting. QUICK_EDIT
Yes when we have specialised hardware like a GPU then estimating the speeds of calculations is very difficult. However I've just been wondering about the future and whether GPUs will end up just being replaced by general purpose processors that have pretty much no specialized hardware in order to leave more space for even more parallelism. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Mar 02, 2013 8:51 am Post subject:
GPGPUs already exist. (CUDA and all the NVidia cards made in the recent 4-5 years) The GPU itself will not get replaced, it will be the software which will have subroutines paralellized upon the GPU.
I just started a course on the uni about this exactly.
I doubt the specialized hardware of current GPUs will get changed, because that's where their advantages of paralellism invoked. The whole thing aims for parallelism, and if you want to generalize the architecture, that means you have to sacrifice from this ability... maybe it'll just left as-is and ends up as a support ALU like the ones back then in 286-era. (387, 487) _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
http://www.moddb.com/games/openra/news/openra-20 has some nice screenshots and explains the progress as well what is left to do in a non-technical way. If you want to help or discuss the implementation details follow http://www.sleipnirstuff.com/forum/viewtopic.php?f=83&t=16215 or talk to Paul directly. We also do a lot of dreaming for the future at http://bugs.open-ra.org/ so if you want to port your mods to OpenRA contact the developers via those channels. I might be the only one reading this thread from time to time. QUICK_EDIT
Do you finally have a gamespeed slider? I find myself falling asleep while waiting dozens and dozens of seconds for a war factory to finish building (I play TS only at speed 5 -> 60 FPS, while OpenRA's speed feels like approximately half of that). _________________ CnCNet Client | CnCNet TS patches | More Quality-of-Life Improvements for RA Remastered
Do you finally have a gamespeed slider? I find myself falling asleep while waiting dozens and dozens of seconds for a war factory to finish building (I play TS only at speed 5 -> 60 FPS, while OpenRA's speed feels like approximately half of that).
We recently unlagged move orders and auto-target. I have the game speed slider done https://github.com/OpenRA/OpenRA/issues/2058 but it is not yet shared to all clients so we can't enable it without breaking multi-player. I can put it on my TODO list again after we tagged a new stable release. QUICK_EDIT
with just OpenRA, custom made SHP(TS) sprites and fake isometry terrain tiles borrowed from C&C ReWire.
very nice _________________ I am authorized to send out the TMP Studio, PM ME IF YOU WANT IT And check this out, these were sent to me for help with terrain and zdata help along with TMP Studio/Builder
You cannot post new topics in this forum You can reply to topics in this forum You can edit your posts in this forum You can delete your posts in this forum You can vote in polls in this forum You can attach files in this forum You can download files in this forum