kazereal
-
Posts
671 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by kazereal
-
-
2018-08-16 03:33:16.748 INFO EDCORE: DABF10C3 0099E6F0 0000:00000000 C:\Windows\SYSTEM32\VCRUNTIME140.dll strchr()+33
This looks like there is lookup trying to find a character in the string and not having terminated the string correctly (null-character). According to call stack it is from Lua-scripting so it might be the script-file or Lua-runtime itself somehow contributing to this (bug might be in the Lua script parser actually).
C++ style string-class usually knows to stop looking after end of string so that would be less prone to this problem, older C-style functions don't have input for maximum string size and this can happen when string isn't null-terminated for whatever reason.
-
Doing that would actually be a rather bad idea because of the comparatively low bandwidth of the connection between RAM and GPU. To render a frame you need to work on big amounts of data to generate even more data and ultimately that data needs to end up on the graphics card anyway. Offloading things to the CPU would most likely cost you huge amounts of performance while the GPU waits for stuff from RAM to be loaded. More cores is mostly beneficial if your CPU isn't able to fully saturate the GPU (and the application properly uses a modern graphics API) or if you're doing lots of stuff that is not well suited to be run on the GPU on the side.
I agree with you: if CPU isn't doing things fast enough you essentially stall the GPU (make it wait for CPU to give more tasks).
PlayStation 4 uses different bus-architecture than PC called HSA-architecture: that essentially allows GPU and CPU share same data without copying between memories. If you had that on PC it could improve efficiency.
Often GPU is more efficient in highly parallel tasks and offloading things from CPU to GPU makes more sense. There are other tasks that don't scale well on GPU and are better to be done on CPU threads: network code is one example of such. So offloading things GPU and threading the rest of CPU would be most useful approach. And simulation code does have plenty of things that can benefit from parallelism if it is done so that it can benefit from parallelism: this means data structures need to work well with this design.
-
Base programming and testing should be finished next month. We'll then work on transferring our shaders to the new API. This is a very new technology for us, and it is quite possible that we will run into unforeseen issues during that phase. DCS World uses many complicated shaders that may not necessarily play nice with the Vulkan API.
Thanks!
Thanks for info! I have been anticipating for this to happen :)
-
Pretty good list of further reading:
-
~3 years of experience and accumulated anecdotal evidence seems to suggest that it's pretty close, but I'd like to know what someone with good physics/math knowledge has to say. Mainly I'm interested in kinematic ranging through either altitude or speed, but anything else is cool too.
Depends what you really mean by that.
If you are asking about inertia and kinetic energy then that is part of the flight model/physics calculation and different aircraft may be using different flight model.
For example, some use AFM, some use PFM and so on so level of implementation might be different.
There is no one single answer to this. The ones that use PFM do simulate things to high degree though. SFM not so much.
Kinetic energy calculations are the very basics of vehicle motion simulation so they do need to be calculated in some level.
Amount of things causing drag and reduction of kinetic might have differences (for example, aircraft skin drag).
Basics of what I am talking about found in every vehicle simulation is energy and loss of it. See wikipedia:
-
Sure. It is probably possible from a technical point of view. If you have an array of REALLY large SSD's that is...
The Caucasus map is approx 500 km2 in size and NTTR approx 600 km2. Together with the currently available modules that requires roughly 60GB of SSD storage space. The surface of the world is approx 500 million km2 so do the math...
On a more serious note, FSX, P3D, XP10 and all the flight sims using the entire world as a playground work very differently than DCS.
1. The scenario is built around landclass and terrain mesh and if you want it to look good you will have to add high-res textures which also would require an insane amount of storage space if you did it for the entire world.
2. In those sims the only interaction with the ground is during takeoffs and landings. In DCS you are supposed to fight in a combat environment. Find ground units hiding etc. That requires a highly detailed scenery.
3. In DCS you need working roads and bridges etc. In the sims you mention that is purely cosmetic and made to look good flying at a bit of altitude. In DCS it should look good at ground level as well. And collision detection is required to work with ground objects in DCS which isn't the case on FSX and other sims.
So a combat flight sim can't really be compared to FSX, XP10 or P3D. But I agree, it would be awesome to fly around the world in a DCS level aircraft and in DCS level scenery. But I'm afraid that it isn't quite possible any time soon.
Adding to that: "plain" flight sims (no sea/ground units) also use procedural generation of things.
This means things like towns and roads are generated by some template/algorithm combination. Towns might be roughly around the location where expected but nothing like the actual town. The addons for a single airfield in those can cost nearly as much as whole terrain module for DCS..
70% of earth surface area is water, so that leaves ~149 million square kilometers of land, but that is still plenty..
Also Nevada map is not 600km2, it is 129600km2 (360*360)
So.. 60 terabytes of data to download..
-
Great news! :thumbup:
-
Really getting excited about this! :thumbup:
-
Hi,
I don't understand the two way to fire guns in this plane.
There are two commands, one with just SPACE, the other one with space and a modifier.
One fire the trigger full, the other one fire the trigger half.
So, what's the difference?
Thanks
First one does not yet fire, just prepares guns for firing.
Second command will actually fire guns.
It makes more sense with a stick that has two "switches" in the trigger (like TM Warthog).
In some WW2-aircraft you might have had machine guns and cannon to be used separately in slightly similar way.
Edit: sorry, thought you were asking about F-5..
Can't remember what the first detend on F-86 does.
-
So are the P51 and Bf109, but those get stuck on the grass (long standing issue in DCS), and the fact that the F5 does not to the same degree makes me wonder what's going on with the tire friction.
Getting stuck on grass, mud, sand etc. is not about friction.
It is about uneven terrain and tyres sinking into unpaved ground (a lot of weight on small surface area of soft ground).
The question is more about how terrain is modelled instead of tyre friction in those cases.
Friction is actually *lower* in unprepared runways: grass and mud are slippery, sand acts like small ball-bearings changing static/glide frictions into rolling friction and so on.
When tyre is sinking it is not about friction but closer comparison would be about soft-body collision with increasing resistance the more material there is in front (the deeper the tyre goes).
-
This should have everything you need:
-
Anyway, this tech demo might have some useful ideas:
-
Furthermore, none of the interior animations seem to work. is this to do with my input file maybe? for example most keys i have noted dont actually work in the mod, example. flaps dont work gear does work so does parachute and eject etc,
But none of the interior animations are showing.
Without ASM code, you'll might need to return values to DCS from FM like this:
https://github.com/ipr/F-16Demo/blob/master/FlightModel/F_16Demo.cpp#L834
Likely some way to do those in lua too but I could never figure out those properly.
-
Second problem, what argument number is the interior cockpit canopy? i tried argument 1 and that didn't work. wondering what is the argument number if anyone knows. the animation works in the EDModelviewer.
Have you tried 38 ? I can't remember exactly now, been a while since touching that code.
https://github.com/ipr/F-16Demo/blob/master/FlightModel/F_16Demo.cpp#L780
-
Parking brake? Not sure but I do believe if you have that on you can't even begin to roll with the plane. Tires burst at way over takeoff speed. Friction I guess.
Toe brakes? None at all, I brake with the keyboard.
Yep, just had an idea to check other possible causes.
If you are using keyboard that means the brakes should not be "half-on/half-off" or anything like that either.
Just checking other possibilities, nothing more.
-
1. When I start DCS for the first time and try to take off in the Hawk, I always fail. Hydraulic pressure looks just fine and elevators move like they should...but no takeoff, I'm glued to the ground and my tires burst eventually.
I have to ask: are you sure parking brake is off?
Tyres should not burst unless there's braking of some sort going on.
There would be other problems as well if it is still on though.
Another thing if toe brake needs to be inverted in the axis tune in options: it would still be on without pressing.
If you press and release brakes a couple of times before takeoff does it make a difference for you?
-
I think this was partially solved before.
There's still some cases like respawn (RShift+RCtrl+Tab) and ejecting very close before hitting ground and such that can cause CTD.
-
ED's implementation of the L39 is far superior to that of the Hawk
L-39 has entirely different in-flight characteristics (different shape of wings for starters).
ED has different code for their flight model, the EFM in Hawk uses entirely different code (which is why it is called *external* flight model).
So your comparison really does not fit there.
The part about "anecdotal evidence" is useless: description by words is very subjective thing.
If you have the numbers to prove otherwise show them, otherwise it is simply based on imagination and many different parameters can be entirely different.
-
2
-
-
While at it, read about specular mapping (used mostly in stuff like glass surfaces):
-
1. Look at this image (yes it's a normal map resaved from DDS 48bbp to jpg 100% 24bpp), tell me you need 280 TRILLION colors capability to properly represent it. With a straight face:
A normal map is not about color information. It is about polygon information.
It contains polygon normal (perpendicular to plane of the polygon in 3D space), which is necessary to know light angle towards the surface.
The normal is used to calculate how much of the polygon surface is lit or if it is not lit at all.
Using normal map is common way to reduce complexity of object geometry by reducing actual polygons from high-poly model and storing normals of the polygons separately. This saves calculation real-time and helps make surface look more "curvy".
I repeat: it is NOT about color information, it contains 3D object information to save processing time.
Read more: https://en.wikipedia.org/wiki/Normal_mapping
-
1
-
-
- Textures are not compressed. Compression was invented and is being used in every single game for a reason. Marginal improvement of uncompressed textures is not worth the inflated size (both on disk and the framebuffer) and additional processing needed.
I have to comment on this bit..
Compression method is often patented. There are various kinds, for example, S3TC (which is lossy compression).
Supporting it needs that makers of software pay royalty to whoever owns the patent.
Skipping the compression allows compatibility and without need for getting licenses to software that support it.
There are open source compression methods with different quality but support is not as wide. Some have written shaders (or OpenCL modules) for GPU that allow uncompressing but usability is not same as having it natively supported.
-
We have to think about current technology and future technology, current systems and future systems hence the three different sets of textures.
Yes. This is the point people are missing entirely here.
Consider that previous DCS engine was used about 8 years I think? (Since standalone Ka-50).
Thinking where graphics hardware will be at 8 years in the future..
-
Computer software will always have more or less glitches.
Just learn to ignore it, that is very small glitch.
-
Or that work required would be enormous for a minor visual glitch.
Or that it needs work that would be obsolete at one point.
Or there are more immediate concerns to solve for any reason.
There are numerous reasons why a bug is not reacted to, often simply it is about prioritizing developer time.
Just because you have it as a pet does not mean everyone cares about it same way, end-users don't see the ton of things happening "behind the scenes", so to speak.
2.5.2.20601@openbeta:MP:Server Crash:C:\Windows\SYSTEM32\VCRUNTIME140.dll strchr()+33
in Game Crash
Posted
This looks more like buffer was not allocated after LAU_127 model was not found and feeding NULL-pointer to strchr() - might be same in both cases actually, depends on how things are implemented in lower-level.