vektorboson

Happy New Year to everyone! God, am I wasted...

First you need to abstract programming languages from their actual implementations; it really depends on the implementation whether the 'programming language' is close to machine code or not. And additionally it depends whether the 'code' is executed in a virtual machine or on actual hardware. To answer your question about 'machine code': There are many different kinds of machine code, or better 'Instruction sets'. As you mentioned the Amiga, you should know that the Amiga-series used the Motorola 68xxx-series processors; they are so called CISC-processors. Then there is the x86-architecture, which includes most of the Intel- and AMD-processors (and several others) which is also CISC. Machine code for 68xxx and x86 is not compatible so Amiga-emulators need to execute 68xxx-code in a virtual machine (unless the programmers go the hard way and translate 68xxx-instructions into equivalent x86-instructions). As the name says, CISC-processors are pretty complex, and nowadays CISC-instructions aren't executed in hardware but are translated in the CPU into RISC-instructions since RISC-architectures are easier to design. To come back to how low-level C/C++ are, well, you can construct a simple translation scheme from C to machine code, as C isn't such a complex language. C++ is almost completely compatible with C, so you could program in C++ like in C. the biggest differences lie within classes (with so called virtual functions) and within template programming. Because of template programming one line of C++-code can generate thousands of machine instructions and one cannot say C++ is very close to machine code. If you really want to be close to machine code, you're better of with the assemblers (every architecture has its own), as every assembler instructions directly translate to a machine instruction. Most compilers work in such a way that it first builds an AST (abstract syntax tree); it then performs semantic analysis and starts to translate the code into 'intermediary code', which is closer to the hardware. This intermediary code may be either optimized or translated directly to assembly/machine code; when you're using Java, what you're really doing is shipping the 'intermediary code' which may be executed on the Java Virtual Machine, or it is JIT-compiled (JIT = just-in-time) and executed as machine code. As for web based languages: They are not converted into CPU-instructions, and god forbid they ever are. The scripts in your web browser are normally executed in a sandbox that should never ever have access to your hardware or system. As for Java being undesirable for programming games. Well, there are indeed games that use Java - I think the Il-2 Sturmovik-series is Java-based, and don't forget all those mobile phone games. One of the biggest problems with game programming is memory management; Java has the problem that everything memory-related is allocated on the heap (in C++ you can decide whether an object-instance should be allocated on the heap or on the stack). If you allocate memory on the heap, it'll take non-deterministic time to find a place in memory that can hold your object. For most applications this is OK as most people won't mind if an action takes a bit longer (although this led to the impression that Java-programs are sluggish/slow); but for games this is a no-go, as you expect to have your constant 60 FPS and don't accept the game to freeze for one second (well don't think further about flight control systems in real airplanes...). Now, C++ has the same problem, but not as much, since small, short-living objects can be allocated on the stack and don't fragment the heap (heap fragmentation makes memory allocation non-deterministic). Thus games need to pre-allocate memory and resources before they go 'live' and never should require memory from the heap when running; every 'malloc' while the game is running may kill the game. So, in Java you need to really plan your memory allocation scheme well out, whereas in C++ you have the stack. Well, it's a lot of reading; you go to Nvidia's or ATI's developer website and download white papers and other stuff. You can also go to Gamedev.net and read through their articles and forums. Or go to the Ogre3d-forums as they often have discussions about graphics hardware. And of course, you need to read Direct3D- and/or OpenGL-tutorials, so you get a view on how those architectures work. To say it in the most stupid manner: Graphics hardware is nothing more that a processor that does linear algebra (see also homogenous coordinates) really good and fast. Of course the GPUs are getting more general purpose and are used for other applications than graphics; protein folding is an example. All I can say is, it's a lot of math. Depending of what type of game you want to develop, and in what detail, you're going to encounter the hardest problems in computing science (this includes games, compilers, operating systems, realtime systems). First thing: You really need to know your algorithms and their complexity (time and space complexity); then you need to really know your toolset (compiler and profiler) to identify the bottlenecks (tipp: it'll be memory, unless you're doing it wrong...). Learn about memory allocation schemes. Learn a lot about hardware and its inner workings. Forget about faster CPUs, it's more important to utilize the memory system efficiently. You need to learn about cache lines and cache hit/miss; you need to learn about branch prediction. CPUs are very fast, but memory is still slow. The OS only provides an infrastructure for hardware drivers, for process management and memory protection (yes, yes and other low level stuff...). In the case of 3D graphics, the graphics driver provides the Direct3D/OpenGL implemenetation that your engine is talking to. For your engine it's nothing more than calling library functions and it's basically unimportant how the hardware is accessed, as it's the driver's job to access the hardware efficiently. Of course, drivers are not perfect and often you need to code workarounds for specific hardware/drivers; perhaps the hardware does not have the capabilities, your engine is requiring? Today, 3D-hardware is being programmed by using shader languages (like HLSL/Cg and GLSL, or frameworks like CUDA) which are translated into a hardware specific representation and executed on the GPU. The CPU isn't doing much, that is probably going to change again, when we see the unification of the GPU and CPU (think of Intel's Larabee).

Some people have already seen the screenshots in the FFUR-thread; I'm working on an addon pack containing GDR, Soviet and US units, from the early to mid 1980s. Hopefully I'll find time (and permission from BWMOD) to create West German units. Here are a few chosen O2 shots (all WIP): This is a NVA- (Nationale Volksarmee) soldier of the GDR (German Democratic Republic), wearing the unique GDR helmet. Thanks to WillyEC for the Base model (DMA Resistance Pack) The East Germans use a custom AKM and AK74; here you see the East German AKMS, named MPi-KMS. Thanks to RHS for the Base model. This is the East German SPW-60PB (soviet: BTR-60PB); you will also see a BTR-60PA. I changed the colors, since I didn't like the green on the original. Thanks to Norsu from FDF-Mod. This is the IPM1, an improved version of the first M1. Contrary to the later Abrams models, this one has a 105mm cannon Also it is painted in MERDC-winter camo. NATO-3 color (as used by Combat! ) was introduced in 1985, but still many vehicles used MERDC. The textures aren't aligned correctly with the model yet, but the model is almost finished. There will be a M1A0 and the IPM1; both, as most of the other US vehicles, will come in three versions: Olive Drab, Summer and Winter MERDC. I may possibly do a Snow MERDC, but I don't know yet. The Chaparral is a modified AIM-9 Sidewinder; here the system is mounted on a modified M548. --- List of planned vehicles: This list is subject to change; a few permissions are still missing, so I cannot guarantee that all vehicles in that list will be in the first release. I'll make a list of included infantry weapons later.

Guys, that's really an awesome M109; right now I don't know whether the Bundeswehr had M109s with the longer barrel (that would be the M109A3G). By my research they used the M109G with the short barrel. The M109 is not very big; the M109A6 from DKM that was used by the COC UA in OFP was way oversized. Look at pictures with soldiers standing nearby, you'll see that the M109 is pretty low. Assuming that smaller soldiers (and not 1.80m guys) are servicing those vehicles, it looks OK.

A M109 MLOD is available by vectorbosons OFP Mod: OFP M109, Mars ++ for OFP When he grants the permission, the MLOD should be pretty good reusalbe for ArmA. I am still working on my own projects, so someone else may ask vektorboson for conversion permission. Nobody needs to ask me, as I'm quite liberal with my work. There is no need to ask permission to use/modify any of my stuff (be it ACES, or the Bundeswehr M113+Artillery pack). Since I'm a (now inactive) P85 member, I would've brought those with me anyway. Nevertheless, I doubt that my models are good enough for ArmA-standards. But they're good enough as place holders.

People interested in game AI, should take a look at this website's blog/archive: http://aigamedev.com/ You'll find a post (and a PDF) about 'terrain reasoning' here: http://aigamedev.com/combat/terrain-annotations In that PDF one of the things you will read is the AI-devs could implement very good AI, but need to 'dumb' it down, so the game is 'playable'. There are many nice articles, sometimes people write about the AI of very old games (I think I've seen an article about Master Of Orion 2). I for sure would love to see someone dissecting the OFP/ArmA-AI and turn it into an article.

Please be patient. I've already said it would be a shame if this would die on my HD; at least some part of this will be released one way or the other. It'll just take some time. Yes, I used llauma-heads with HYK's face textures. Of course there are; I'm using RHS GAZ-66, Manfred's URAL 375/4320, MT-LBs and CSLA mod's AMBS (Ambulance BMP). The US were supposed to receive the M809-series trucks; so there it's lacking. I've only completed the medical M113A2. But there is someone who might take this over, and I don't know what he has got in his pipeline.

As for my OFP file tools, I made some progress; though I had no time for a month now to do anything. As for this Mod: I've joined the ArmA Project '85-Mod, so I'm not gonna finish this mod. I'll try to release some of the addons, as it would be really a shame if they stay on my HD (and they are not suitable for ArmA anyway). But it may take a while until I have enough time to do this.

There's always my German Artillery pack which includes the German version of the MLRS: http://www.flashpoint1985.com/cgi-bin....t=58700 It requires the already mentioned COC Unified Arty pack. Please note: The whole pack is free to modify, so the MARS may be changed into a MLRS by anybody.

Of course there are many many differences between OFP and ArmA, not only regarding the rendering, but also the artwork. In OFP, models were made up from far too many 'sections' (every section needs a render state switch). This may have been OK in time of hard-wired graphics pipelines, but it is no more acceptable for the programmable GPUs, since there is a lot going on when switching shaders a.s.o. In this case, ArmA's models are much more optimized for today's hardware. This efficiency gain is used for much more detailed units (thus neglecting the potential increase of FPS). As for rendering, OFP used simple per-vertex-lighting, whereas ArmA has a much more complicated light-model for the sun (HDR, shadow map/volume, a.s.o.) that requires lots of GPU-power more compared to OFP's light-model. Also, ArmA's terrain rendering is much better than OFP's highly inefficient terrain. I don't know whether OFP optimized the terrain by grouping neighbouring tiles with the same texture into one render batch: My guess is not. In the worst case OFP had to switch texture for every terrain cell you see on the screen. The other inefficiency was: Transition textures. The transition textures took a lot of GPU-memory; ArmA uses texture splatting to render different surfaces in a cell. Thus transitions are created by texture filtering in hardware and don't take texture memory that may be used up by more detailed textures. As said, ArmA's artwork is much more detailed; there was also a post by Maruk or Suma (don't remember who, but it was in one of the Vegetation performance threads) who said that ArmA has problems with overdraw -> engine is pixel-bound. One of the solutions is indeed: Throw a GPU with more fragment processors at it (though newer GPUs are reconfigurable, so they can dedicate more processing units to fragment operations). Others are: Reduce screen resolution, better culling (especially occlusion culling) algorithms, less demanding shaders. For Rasterizer-based graphics, the CPU doesn't do any rendering: It just fills the GPU-memory with the geometry/texture data, sets up the render state and tells which buffers to render.

I'm also missing Microprose... they made so many cool games back in the days... Civilization, Railroad Tycoon, F117 Nighthawk, Master Of Orion, a.s.o. Well, it depends on what you do: I wanted to fly a Cessna from Stuttgart to Munich. So I took an old school atlas and a ruler and measured the distance and angle between both cities. I estimated at which time I should see what cities/towns at which side of my plane, so I could be sure that I'm flying the right direction. Then I indeed arrived at Munich with a difference of 5 minutes to my ETA, the only navigational aid being a compass and an old school atlas. No HUD, no NavPoints, no ILS, no VORs a.s.o.

I once had the same problem, but I was using WrpEdit back then. I also don't remember how I fixed the problem; it was either by reapplying the texture to the cell, or I fiddled with the options for that cell (like roadway or such...)

Which program are you using for island creation?

According to the output in that thread, the problem is with floating point textures. As you can see, floating point textures are on the TODO-list: http://wiki.winehq.org/DirectX-ToDo Now, I think I've read that it isn't possible to disable HDR in ArmA. In case it is possible, try to disable HDR and look if 3D works then.

Of course you're right in the case of tech-savvy users. But I'm also talking of 'sister', 'mother', 'grand-mother', 'girl-friend' and 'neighbour' types of users. And they are definitely not the technically competent people as I had to teach them how to use a VCR despite a nice and understandable handbook and on-screen-help. I always expect the worst when a Windows-user asks for help... (which doesn't imply Windows is non-usable, it's just not suitable for beginners IMHO) But sorry for all the OT.

The problem with OpenGL was, AFAIK, that Microsoft was a member of the OpenGL ARB (OpenGL 'standards committee' and kinda 'sabotaged' / slowed down the improvement of OpenGL. After MS left the ARB, the core OpenGL started to catch up; but they should've been on par regarding features (because hardware vendors may implement extensions to OpenGL, without the need to wait for the next OpenGL-version). As for no commercial games being made with OpenGL: AFAIK games for Playstation 3 and Wii are made with OpenGL; the same is true for games on the Mac. And now for something completely different: Would I suggest someone to use Linux as their Desktop OS? Yes. Especially if they've never used a PC before. I have less help requests from people who use Linux than Windows; of course there are problems when people give them Windows-only software and they don't understand why it doesn't work (*cough* most of the time it's pirated).

It's already in there for a very long time. Â

Well, I'm programming it; it'll use NVidia's texture atlas tool for merging (like Synide's moveUV-tool).

Sry, that one was sacrificed for a personal shift of priorities. Â Well, no problem I guess. In case your already released CH-47 is similar enough to US CH-47, then it would be nice if you could send me the necessary files, and I'd retexture it myself.

Hey Q, a better solution would be to take the Faces from HYK's US Soldier's addon; he transformed the original BIS faces to the Llauma-head model, which has a very similar texture mapping.

What you try to achieve is already possible; I hope you know how to define 'sections' (or anchors) in a briefing, and how you create links to these sections. For every group you create an objective that links to their specific part of the briefing. Just hide those objectives for groups/players who shouldn't read them.

The point is, that those models from which you make the buildings need to be suitable for this type of functionality. They need to be suitable for placing them with the editor, and they need to be suitable for creating a P3D from them. The easiest solution of course is to just place those models exactly at the same (relative) position like in the editor. But that's not enough; you need to also think about the non-visual LODs, like Geometry, Roadway a.s.o. Especially the Geometry-LOD could get excessive if every single part gets its own component (whereas you could just make a straight section of wall parts into a single component). So one needs additional information how the different building parts work together. Unless, of course, you prefer to create those LODs yourself.

This is really a great idea. Do you think that it is possible? It would be the foundation stone for the construction of a huge object library  Of course this is possible. The best approach is: 1. Someone creates a suitable set of placeable models (walls, windows, doors, floors, etc.). I don't know the restrictions of setObjectTexture in ArmA, but you could dynamically set the wall- and floor-textures. If you ever played 'The Sims', I think that this could indeed be accomplished in your editor. 2. You then create a script (or some comparable output), like you do for Visitor; then a tool (I guess it would be written by me...) parses that file and creates a P3D (of course it could optimize the model by merging vertices for adjacent walls a.s.o.). 3. We have the most funky crazy ingame editor of all time! Imagine an island consisting of the whole community's personal houses!  If you really want to go this path, you can always contact me for technical consulting. But I hope that this won't delay the release of this wonderful project. EDIT: As Q mentioned SVN for version management (OK for distributing binary files like Q said), but for distributed projects (scripting a.s.o.) I'd consider using  Mercurial or the graphical UI TortoiseHG.

Really cool, perhaps I should finally buy Arma  This reminds me of something we semi-realized for OFP (@Silola: remember?) I liked how you used 'wall parts' to create a 'building' 'The Sims'-style (the crazy guy in me says: Use this to create buildings which can then be converted into a P3D). Â

Hi guys; I'm doing something similar for OFP (see Flashpoint Germany-thread), and I'm planning to use the Texture Atlas-tool, too. But I'm not using DDS utilities, but ImageMagick (specifically convert.exe). It can apply many transformations/filters and has many input/output formats (I'm using it to convert DDS to TGA/PNG), and it has the advantage that you're allowed to redistribute it. Could you explain, in which way it doesn't work (as I may find the same problems)?