Search the Community
Showing results for tags 'opengl'.
https://en.wikipedia.org/wiki/Raspberry_Pi https://www.raspberrypi.org/products/raspberry-pi-4-model-b/ https://www.raspberrypi.org/products/raspberry-pi-4-model-b/specifications/ https://www.tomshardware.com/reviews/raspberry-pi-4-b,6193.html https://www.anandtech.com/show/14581/raspberry-pi-4-launched-quad-cortex-a72-project-board-for-35-dollars https://www.raspberrypi.org/magpi-issues/MagPi83.pdf Major improvements across the "board". The quad-core Cortex-A72 with other improvements is anywhere from 25% to 300% faster than the A53 used in the Raspberry Pi 3 . No eMMC but an SSD could be used with one of the two new USB 3 ports (booting from USB or Ethernet not supported at launch, should be ready within weeks). There are three RAM options: 1 GB ($35), 2 GB ($45), 4 GB ($55). The RAM is now LPDDR4 instead of LPDDR2. The 2 GB option is a bit unnecessary IMO and seems to be the least popular, as it's the model least likely to be sold out online (as far as I can tell). Ethernet speed can actually hit close to 1 Gbps (943 Mbps), up from 237 Mbps. There is Bluetooth 5.0 support but I haven't seen any testing related to that (I would love to use it for longer range audio transmission to BT 5.0 headphones). RasPi 3 cases are incompatible due to some port shuffling. There are now two micro-HDMI ports instead of one full size HDMI, so you probably need a new cable. The device can output to two 4K displays at 30 FPS, or one 4K display at 60 FPS (presumably two 1080p displays @ 60+ FPS, and so on). Although the new GPU has 4K@60Hz H.265 decode support, actually streaming 4K and even lower resolutions on Raspbian had issues in testing, that will hopefully be resolved with updates soon. LibreELEC developers have been working with the Pi Foundation for months to support the Pi 4, and have an alpha version out. Power draw and heat are up. You'll probably want a FLIRC case or something that can provide cooling. Power is now provided using a USB Type-C cable. Due to a screw up by the Raspberry Pi Foundation, some USB-C cables don't work. But the ones that do work should be the cheapest. Can it run TDM? The CPU and GPU are much better and the potentially quadrupled RAM could be a big help. The 4 GB version can be a legitimate desktop replacement for many users, albeit with some quirks.
As most players will surely agree, one of the things that make TDM great are its visual capabilities, which come from idTech 4 having been so well designed. As I've been playing more with rendering and game engines during the last period, I realized this is something worth bringing up in the graphics department. I dare suggest it since frankly, TDM has some of the best graphics in the world of open-source games today... the idea of adding a common effect that would rocket its visual quality even higher sounds acceptable enough to post about. Typically there are two light occlusion effects, though I can imagine them combined in one by a smart renderer: Ambient Occlusion to simulate darkening in tight spaces, and Global Illumination to simulate light reflecting off surfaces. They're often costly to calculate for realtime lights, but there are engines that do it right... Tesseract (FPS based on Cube 2) offers a great example of doing FPS-cheap GI! A more serious problem specific to TDM is that this would affect the brightness of areas, and in turn the gameplay on existing maps... it would need to be an user option for this reason. I'm mostly curious on the opinions of the devs; Could at least SSAO be considered at some point, if not an implementation for radiosity? Some examples of why this is so awesome.
I hope this isn't a useless thread, just thought it would be constructive to let everyone know about it. I was looking up some TDM related concerns, and accidentally stumbled across another fork of the idTech4 engine. It's called fhDOOM, and it seems to have a lot of neat graphical improvements over the stock engine. eXistence/fhDOOM There are definitely things in there that TDM could consider grabbing! Some important ones highlighted on their front page: Modern renderer based on OpenGL 3.3 core profile. Any up-to-date engine should have this as a norm.Parallax mapping. Not sure if we have this already... I only know the original engine had simple bump mapping.Soft shadows. A heavily desired and long awaited feature.Alpha textures affecting shadows. This allows light to shine through textured grates, which is a very beautiful improvement.Soft particles. This one we already have now however.An example of the old lighting system (ours) versus lighting with shadow mapping (fhDOOM): As the obstacle to new features is almost always finding someone willing to code them, discovering those improvements for our engine is a goldmine... since unless they conflict with any of our changes, I assume they should be easy to just plug into the code. Can any of this good stuff please be considered for inclusion in TDM's version of the engine?
I recently saw a post about the functionality of the idTech 6 engine, which brought this suggestion to my attention. It's actually a simple and trivial improvement, although I can imagine people missing it and not thinking about its absence. Also keep in mind I don't know the lighting code of TDM, and everything I say is purely out of observation. Like most engines that use dynamic lighting, TDM tends to have considerable performance issues when a lot of lights are rendered at once. This is often because of shadows and possibly other calculations. A common way to prevent extra computation in the renderer is caching all lights, and only updating each one when necessary. Meaning either the light itself has moved, or something is moving in front of the light. If both the light and the geometry it affects are static, there is nothing to recalculate, which offers a significant performance boost. TDM has a serious problem here: Even if the engine already knows how to cache lights, every torch has a moving light source! If you look closely at a torch, you'll notice its shadows constantly bob around. While this makes sense aesthetically, it also means that light will be recalculated each frame... even if the torch is mounted on a wall and no physical object or NPC is currently moving within its radius. Since most maps use torches and have areas where characters don't walk in front of them, I see a notable performance improvement being lost here. My personal suggestion: First of all, does idTech 4 support light caching for static lights + geometry to begin with? If somehow the original engine didn't have that, I definitely think it should be patched in! Once that's solved, I believe moving light sources for flame based lights should be controlled by a cvar; If people are okay with the performance loss, they can enable that to get bobbing shadows... if not, disable to allow torch lights to be cached and improve overall FPS. An idea to compensate for the visual loss: Can't we use an animated light texture to simulate moving flames altogether, as well as pulsating brightness? The light bobbing looks pretty extreme anyway: In real life, candles have a smooth flame that casts a neat shadow, and shadows don't always move that chaotically even when it's a noisier flame like a campfire.