#directx

[gargaj]

How to engine - a quick tutorial

A few weeks ago I decided I am fed up with the current state of things particularly in the demoscene (but also a bit in game development) when it comes to using a prepackaged engine versus people knowing or learning how to use their own thing, so I put together a quick tutorial for how to write the beginnings of a framework that renders a mesh and plays some music - it took less than 400 lines of C++ and about 40 steps.

Is it perfect? No, of course not, nothing is ever perfect or finished, but my hope is really to dispel this notion that writing rendering code is the privilege of a select few, because it's easier than people think.

[cyazurai]

That voyage is so complete it killed DirectX.

[mvfm-25]

" Behind the scenes with the creators of the most powerful game machine on the planet! "

NextGen Magazine n68 - August, 2000.

[somethingblu3]

Does anyone know how to fix these direct crashes? it's really annoying. I thought I had fixed them but it keeps happening every time I load the game.

[retrocompmx]

Efemérides Tecnológica: 5 ded junio de 1996. Se libera DirectX 2.0a, y comienza la era dorada del gaming en PC

El 5 junio 1996, Microsoft lanzó DirectX 2.0a 🎮 Esta API finalmente hizo de Windows 95 una plataforma viable para el gaming, liberando a los desarrolladores de DOS. El inicio de una era dorada para los juegos de PC. #retrocomputingmx #DirectX #windows95 #pcgaming #historiadelosvideojuegos

[q39engine]

If you want to render a randomly generated terrain in 3D, one way is to simply generate a height for each point on a grid (height map). It’s easy to triangulate the grid squares and create a mesh. But if you want to create terrain that might have overhangs or caves, you can’t use a height map. (What is the value of the height map at an overhang? There is no longer a unique value.) To generate terrain that might have these features, you generally need some kind of contouring algorithm.

For 3D modeling in general, I’ve found the dual contouring algorithm to be invaluable. But when I tried to render terrain with dual contouring, I immediately encountered various problems, and it was far from clear that there were even good solutions to these problems. It’s possible that I didn’t spend enough time with it. But since I had already experimented a bit with marching cubes for terrain generation, I decided to pursue that approach. No matter which algorithm you choose (and there are others), there will be certain problems that have to be addressed. But at the time, the problems with marching cubes seemed less severe.

One of the main problems turned out to be levels of detail (LODs). For performance and efficiency reasons, you want to render the nearby geometry at a high resolution and the distant geometry at a progressively lower resolution. If you do this with marching cubes, the first thing you see is that there are gaps in the geometry between the levels of detail. The reason is that if you approach this naively, LODs basically break the marching cubes algorithm in an obvious way. For a long time, I thought there must be some relatively simple trick to overcome this difficulty. Ultimately, I found that the only “trick” is to apply a very logical, methodical approach. The seams (gaps) between the LODs can be “fixed”. The seams can be closed perfectly -- without adding any extraneous geometry. To summarize how this is done in a single sentence: It does involve calculating the precise point at which the surface crosses voxel boundaries at the seam and using only that (or those) point(s) when constructing the marching cubes triangles for those voxels.

Here are two images. One shows marching cubes terrain with the levels of detail regions color-coded. The innermost region is brown, then green, yellow, red and light blue (the lowest resolution, which could extend indefinitely). There are some light blue and white triangles in between that serve debugging purposes (and orange triangles are at the LOD boundaries, likewise for debugging and visualization). The other screenshot shows a closer view of the seam between two LODs. This is always a perfect seam. There are never any gaps, and there is never any “extra” geometry.

[gamebuntu]

Открытый код компилятора шейдеров DirectX

Еще в 2017 году был представлен первый этап разработки шейдерного компилятора DirectX с открытым исходным кодом, и с тех пор Microsoft продолжает совершенствовать его, улучшая поддержку Linux, добавляя новые функции и устраняя другие недочеты в проекте «DirectXShaderCompiler». Недавно компания выпустила новую версию этого DirectX Shader Compiler, в которой появился еще один новый компонент с открытым исходным кодом.

https://www.gamebuntu.ru/news/otkrytyy-kod-kompilyatora-sheyderov-directx/

[brunorosenbaum11]

Shader Programming: 3D Scene using Direct 3D 11 - 3rd Year Project

My favorite project I made while I was an undergrad! This was the first time I used Direct 3D, HLSL and coded my first shaders.

I had no idea about shaders prior to this project - I had only dabbled in OpenGL, but wasn't aware of the graphics pipeline, nor that GPUs were programmable.

That said, the whole module fascinated me. It was so engaging, and I loved the way algorithms and vector maths could be implemented to draw and render shapes and effects on the screen.

The scene makes use of the vertex, hull, domain and fragment shaders, for geometry manipulation and post processing effects.

All of the shaders were written from scratch using VS and the D3D11 graphics API, in C++ and HLSL.

You can read more about the project here!

[govindhtech]

Improved Malware Analysis with Google Gemini 1.5 flash

Gemini 1.5 flash

Google cloud looked at how Gemini 1.5 Pro may be used to automate malware binaries’ code analysis and reverse engineering in Google’s earlier post. Google cloud is now concentrating on Google Gemini 1.5 flash, Google’s new low-weight and affordable model, to move that analysis out of the lab and into a production-ready system that can analyse malware on a massive scale. Gemini 1.5 Flash can handle heavy workloads and offers remarkable speed, handling up to one million tokens.

Google cloud developed an architecture on Google Compute Engine to accommodate this, including a multi-stage workflow with stages for scalable unpacking and recompilation. Although encouraging, this is only the beginning of a long road to address accuracy issues and realise AI’s full potential in malware analysis.

Every day, 1.2 million unique new files that have never been seen on the platform before are analysed by VirusTotal on average. The binary files that make up about half of these could be useful for reverse engineering and code analysis. This amount of new threats is simply too much for traditional, manual ways to handle. The task of developing a system that can quickly and effectively automatically unpack, decompile, and analyse this amount of code is formidable, but Google Gemini 1.5 flash is intended to assist in overcoming it.

Expanding upon the wide range of features of the Gemini 1.5 Pro, the Gemini 1.5 Flash model was designed to maximise speed and efficiency without sacrificing performance. While both models can handle a context window of more than a million tokens and have strong multimodal capabilities, Google Gemini 1.5 flash is specifically made for quick inference and low deployment costs. This is accomplished by using online distillation techniques in conjunction with the parallel computation of feedforward and attention components.

With the latter, Flash can pick up training knowledge directly from the bigger and more intricate Pro model. With the help of these architectural improvements,Google cloud handle up to 1,000 requests and 4 million tokens per minute on Gemini 1.5 flash.

First, we’ll provide some examples of Google Gemini 1.5 flash analyzing decompiled binaries to demonstrate how this pipeline functions. After that, quickly go over the earlier phases of unpacking and large-scale decompilation.

What is Gemini 1.5 Flash

Google AI built Gemini 1.5 Flash, a big language model. It is the fastest and most cost-effective model for high-volume jobs at scale.

Key Gemini 1.5 Flash features:

Speed: Processing 1,000 queries and 4 million tokens per minute, it is extremely fast. This makes it perfect for real-time applications.

Cost-efficiency: This Gemini 1.5 Flash model is more cost-effective than others, giving it a budget-friendly choice for huge projects.

Long context window: A startling one million tokens can be handled by 1.5 Flash, despite its lightweight nature. This lets it consider a lot of data when answering prompts and requests, providing more detailed answers.

Gemini 1.5 Flash balances speed, price, and performance, making it useful for large-scale language processing jobs.

Gemini 1.5 flash Model

Analysis Speed and Illustrative Cases

Google cloud examined 1,000 Windows executables and DLLs that were chosen at random from VirusTotal’s incoming stream in order to assess the real-world efficacy of Google’s malware analysis pipeline. This selection process guaranteed a wide variety of samples, including both malware and legitimate applications. The speed of the Gemini 1.5 Flash was the first item that caught Google’s attention.

This is consistent with the performance benchmarks reported in the paper by the Google Gemini team, where Google Gemini 1.5 flash surpassed other large language models time and time again in terms of text creation speed across a variety of languages.

Google cloud observations showed that the fastest processing time was 1.51 seconds, and the slowest was 59.60 seconds. Google Gemini 1.5 flash handled each file in an average of 12.72 seconds. It’s crucial to remember that these periods do not include the unpacking and decompilation phases, which Google cloud will discuss in more detail in a subsequent blog article.

The length of the ensuing analysis and the amount and complexity of the input code are two examples of the variables that affect these processing timeframes. It’s significant that these measures cover the whole process from beginning to end: from sending the decompiled code to the Vertex AI Gemini 1.5 Flash API, to having the model analyse it, to getting the whole answer back on Google Compute Engine instance. This end-to-end view demonstrates the fast and low latency that Google Gemini 1.5 flash can achieve in actual production settings.

Example 1: It Takes 1.51 Seconds to Dispel a False Positive

This binary was processed the quickest out of the 1,000 binaries Google cloudexamined, demonstrating the exceptional performance of Gemini 1.5 Flash. One anti-virus detection was triggered by the file goopdate.dll (103.52 KB) on VirusTotal, which is a frequent occurrence that frequently necessitates a laborious human review.

Imagine that your SIEM system sent out an alert due to this file, and you urgently need a response. In just 1.51 seconds, Google Gemini 1.5 Flash analyses the decompiled code and gives a clear explanation, stating that the file is a straightforward executable launcher for the “BraveUpdate.exe” application, which is probably a web browser component. Analysts can safely reject the warning as a false positive thanks to this quick, code-level knowledge, avoiding needless escalation and saving crucial time and resources.

Taking Care of Another False Positive, Example 2

Another file that needs more investigation is BootstrapPackagedGame-Win64-Shipping.exe (302.50 KB), which was reported as suspicious by two anti-virus engines on VirusTotal. In just 4.01 seconds, analyses the decompiled code and discovers that the file is a game launcher.

Gemini describes the functionality of the sample, which includes locating and running redistributable installations, verifying for dependencies such as DirectX and Microsoft Visual C++ Runtime, and finally starting the main game executable. This degree of comprehension enables analysts to classify the file as legitimate with confidence, saving time and effort by preventing the needless investigation of a possible false positive.

Example 3: Using obfuscated code, the longest processing time

During Google cloud investigation, the file svrwsc.exe (5.91 MB) stood out for needing the longest processing time 59.60 seconds. The lengthier analysis time was probably caused by elements like the quantity of the decompiled code and the use of obfuscation methods like XOR encryption. Still, Google Gemini 1.5 flash took less than a minute to finish its study. Considering that it could take a human analyst several hours to manually reverse engineer such a binary, this is a noteworthy accomplishment.

Gemini identified the sample’s backdoor functionality which is intended to exfiltrate data and establish a connection with command-and-control (C2) servers situated on Russian domains and correctly concluded that it was harmful. Numerous indicator of compromises (IOCs) are revealed by the study, including probable C2 server URLs, mutexes employed for process synchronisation, changed registry entries, and dubious file names. Security teams can quickly analyse and address the threat thanks to this information.

Example 4: A miner of cryptocurrency

In this example, the decompiled code of a cryptominer called colto.exe is analysed by Google Gemini 1.5 flash. It’s crucial to remember that VirusTotal provides no further metadata or context for the model; it just receives the decompiled code as input. Google Gemini 1.5 flash completed a thorough analysis in 12.95 seconds, recognising the malware as a cryptominer, highlighting obfuscation strategies, and extracting important IOCs like the file location, wallet address, download URL, and mining pool.

Example 5: Using an Agnostic Approach to Understand Legitimate Software

In this example, Gemini 1.5 Flash analyses 3DViewer2009.exe, a valid 3D viewer programme, in 16.72 seconds. Knowing a program’s functionality can be useful for security reasons even if it is goodware. It is critical to note that the model does not receive any extra metadata from VirusTotal, such as whether the binary is digitally signed by a trusted institution, and that it just receives the decompiled code for analysis, exactly like in the prior examples. While standard malware detection algorithms frequently consider this information, Google cloud are taking a code-centric approach.

Google Gemini 1.5 flash is able to identify the main function of the application, which is to load and show 3D models, as well as the particular kind of 3D data that it works with, which is DTM. The examination emphasises the use of custom file classes for data management, configuration file loading, and rendering using OpenGL. Security teams may find it easier to distinguish between genuine software and malware that might try to replicate its actions with this degree of comprehension.

This functional-only, agnostic method of code analysis may prove especially helpful when examining digitally signed binaries, which may not necessarily receive the same level of security scrutiny as unsigned files. This creates new opportunities to spot possibly harmful activity even in software that is meant to be trusted.

Taking a Closer Look at a Zero-Hour Keylogger

This illustration demonstrates the actual value of looking for malicious activity in code: it can identify risks that are missed by conventional security solutions. When the executable AdvProdTool.exe (87KB) was first uploaded and analysed, it avoided being detected by any anti-virus engines, sandboxes, or detection systems on VirusTotal. But Google Gemini 1.5 flash reveals its actual nature. The model analyses the decompiled code in 4.7 seconds, recognising it as a keylogger and even disclosing the IP address and port where stolen data is exfiltrated.

The research focuses on how the code creates a secure TLS connection to the IP address on port 443 by using OpenSSL. The use of keyboard input capture functions and their link to data transmission over the secure channel are crucially called out by Gemini.

The ability of code analysis to detect zero-hour risks in the early phases of development, as this keylogger seems to be, is demonstrated by this example. It also draws attention to a crucial benefit of Gemini 1.5 Flash: even in cases when malicious intent is concealed by metadata or detection evasion strategies, examining the basic operation of code might uncover it.

Overview of Workflow

Gemini Flash 1.5

Three essential steps comprise Google’s malware analysis pipeline: unpacking, decompilation, and Google Gemini 1.5 flash code analysis. The first two stages are driven by two key processes: large-scale decompilation and automated unpacking. Google cloud use in-house cloud-based malware analysis service, Mandiant Backscatter, to dynamically unpack incoming binaries.

Next, a cluster of Hex-Rays Decompilers running on Google Compute Engine processes the unpacked binaries. Gemini can analyse decompiled and disassembled code, but we have chosen to use decompilation in Google pipeline.

Given the token window limits of big Large language models, the deciding decision was that decompiled code was 5–10 times more concise than disassembled code, making it a more efficient alternative. Google Gemini 1.5 flash is finally used to analyse this decompiled code.

Google cloud handle a vast amount of binaries, including the full daily flood of over 500,000 new binaries submitted to VirusTotal, by coordinating this workflow on Google  Cloud.

Read more on Govindhtech.com

[dkplayer]

VKD3D 1.12

Выпущен VKD3D 1.12 с поддержкой прямого вывода сборки шейдеров SPIR-V и D3D.

https://www.gamebuntu.ru/news/vkd3d-1-12/

[bitrise-co-in]

Jacob Roach / Digital Trends Microsoft has released Agility SDK 1.613.0, which features some critical components that will be presented to developers at the Game Developers Conference (GDC) in San Francisco next week. The most interesting elem... bitrise.co.in

[semi-imaginary-place]

Last year i actually did figure out why ffxiv is always crashing for me. It's Microsoft's shitty design, don't buy their Surface series if you want a functional graphics card. The Nvidia graphics card along with a lot of the physical components like keyboard, touchpad, brightness buttons are in the keyboard section of the laptop, while the critical components and Intel graphics card are in the main computer/screen half of the laptop. The hinge is poorly designed so the physical connection between the two halves is unstable. Like literally sometimes smacking the computer a bit would cause them to reconnect. I was seeing this problem with FFXIV mainly for 2 reasons I hypothesize. 1 FFXIV was what I was mainly needing the Nvidia graphics card for a lot of other things I didn't notice a performance drop because I wasn't using it often for intensive activities. 2 I was leaving the game running for many hours (like gaming all Saturday and just leaving the game on for 6 hours) at a time and it was running hot for so long that might have affected the physical connections. If I so much a nudge my powerstrip sometimes it hiccups and my power cable is held together with duct tape so when my laptop switched to battery power the game would crash.

[retrocompmx]

Un día como hoy (9 de noviembre) en la computación

El 9 de noviembre de 2000, Microsoft lanza la versión 8 de su software de interfases de programación de aplicaciones que gestionan actividades de multimedia sobre todo en video juegos y video, Direct #retrocomputingmx #retrogaming #DirectX

[q39engine]

Given a 3D scene, you’ll want some way to easily interact with the rendered objects. So I’ve implemented “picking”. In other words, if I want to select the orange cuboid (or a certain part of it), I simply click on it -- and presto, the application gives some kind of feedback to indicate that I’ve selected that particular object or primitive. Doing this properly requires a good understanding of the 3D rendering process: a good understanding of the basics of projecting a 3D scene onto a 2D surface (the computer display). Here, I’ve clicked on a primitive (a triangle) of the orange cuboid, and it turned green in response.

This is set up as a debugging example so that I can pick any triangle in the orange cuboid. But suppose I want to click on any object in the scene. It’s inefficient to manually check each rendered object directly to find out whether my mouse click is picking that particular object. To allow this sort of functionality efficiently, I need an extra data structure that basically knows the position of each rendered object, so that when I click on the green prism, for example, the application already knows the general region of space where I’m clicking, and knows there’s nothing there but the green prism. This extra structure I need is called a "bounding volume hierarchy" (BVH). And fortunately, that’s a fairly straightforward thing. (Still in the works at the moment.)

[gamebuntu]

VKD3D 1.15

Вышла новая версия проекта VKD3D 1.15 для реализации API Microsoft Direct3D 12 поверх API Vulkan, что позволяет улучшить работу Windows-игр на Linux и других рабочих нагрузок D3D12 на Linux или macOS в паре с MoltenVK.

https://www.gamebuntu.ru/news/vkd3d-1-15/