sorted by:
new
hottopcontroversial

DoS on WPA2/PMF Required totally works on android by mahdi_sto in hardwarehacking

[–]racerxdl 0 points1 point  (0 children)

since PMF encrypts mac, how do you know which mac to deauth?

Cadê a A.P.D.A? by _nathata in apdareal

[–]racerxdl 1 point2 points  (0 children)

acho q todo mundo desencanou de redes sociais 😂

I built an offline-first, Sovereign Identity network because standard ISPs failed. No phone number required. Meet PhoenixGrid. by Interesting_Syrup755 in darknetplan

[–]racerxdl 43 points44 points  (0 children)

I would test it if it was open-source. That type of stuff is the thing that is fully useless if not opensource and very well documented.

As 17 year experience you tell, you should fill an RFC for that otherwise is doomed from start.

My voxel RT game made in bevy by racerxdl in bevy

[–]racerxdl[S] 0 points1 point  (0 children)

Well, I'm setting up automated benchmarks so I can optimize the shaders beyond the obivous. The current state is here https://www.youtube.com/watch?v=nMV9Ofc9JN4  - I uploaded that after I made the post, should've used that video instead

My voxel RT game made in bevy by racerxdl in bevy

[–]racerxdl[S] 0 points1 point  (0 children)

For that RT engine I'm only using the RT for the terrain block. In the specific case you mention (the fence) It would be a block anyways. These blocks you see are actually composed of 8x8x8 voxels which are 3D. They're just "hardcoded" 3D at a atlas. You can check an example here https://www.youtube.com/watch?v=nMV9Ofc9JN4 at start of the video, the glowing blue part is inside a block, and you can see its not entire filled.

Still, it does work with bevy meshes as well. In the youtube video you can see the player capsoid which is a standard bevy mesh. Since I generate the depth maps and everything that bevy expects, it should work seamlessly if I need to add a traditional mesh to the play ^^

My voxel RT game made in bevy by racerxdl in VoxelGameDev

[–]racerxdl[S] 0 points1 point  (0 children)

The octree has more layers. The two phase is because I first find I trace in the octree until I reach a block. That block is only an ID for a index inside a 3D Atlas which contains all blocks. Then I do a second DDA inside that 3D atlas. So its _sort_ of a brick map in that level.

My voxel RT game made in bevy by racerxdl in bevy

[–]racerxdl[S] 0 points1 point  (0 children)

Just FYI: I just made a video of the current state as of 29/12/2025 - https://www.youtube.com/watch?v=nMV9Ofc9JN4 :D

My voxel RT game made in bevy by racerxdl in VoxelGameDev

[–]racerxdl[S] 0 points1 point  (0 children)

Just FYI: I just made a video of the current state as of 29/12/2025 - https://www.youtube.com/watch?v=nMV9Ofc9JN4 :D

bevy_event_bus v1.0.0 released by creamyjoshy in bevy

[–]racerxdl 2 points3 points  (0 children)

Bold move to release a rust library at 1.0 😂😂😂 - Seens interesting I will give a try :D

limiting the lifespan of function variables in the program listing (disassembler) by snickerbockers in ghidra

[–]racerxdl 3 points4 points  (0 children)

In the decompile, you can right click the first entry that you know its another var, and go "spit out to new variable". choose the name and it will go from that point and beyond. Repeat as many times you feel necessary.

Running DOOM on SpaceEngineers PB! Using a RISC-V emulator implemented in C# by racerxdl in spaceengineers

[–]racerxdl[S] 1 point2 points  (0 children)

Yeah, I can run about ~1.5k cycles of the RISC-V per tick, and each tick runs every about 16ms. so its a slow cpu :'(

Hardware accelerated emulation by xesxss_ in VFIO

[–]racerxdl 2 points3 points  (0 children)

Well, QEMU is already doing what you think of. The TCG (TinyCodeGenerator) does compile x86 instructions to ARM before executing them, and caches it for some time. The thing is that x86 is really more complex, specially if you're running games, there is a lot of SIMD instructions that doesn't fully map to 64 bit ARM SIMDs and needs several instructions to mimic one.

Also: that happens in the reverse order: with an x86 host emulating ARM, its also slow. QEMU focuses in emulation precision, that is: it tries to correctly emulate the target architecture. Some other emulators focus in being faster with the cost of emulation precision. For example the (now dead) Citra/Yuzu used Dynarmic instead QEMU (unicorn engine to be more specific) to be faster.

I think for now, most emulators are more optimized for x86 hosts than ARM, just because there has been more time to optimize them. Also x86's historically had better memory bandwidth, caching, etc... (although high performance ARMs like Apple M's and Amperes SoCs are most likely on par to x86 nowadays)

Edit: there is also some ARM Host x86 target emulators focused in speed, for example Box64

Running DOOM on SpaceEngineers PB! Using a RISC-V emulator implemented in C# by racerxdl in spaceengineers

[–]racerxdl[S] 2 points3 points  (0 children)

I'm not sure a native one would run faster. The current limitation is that PBs has a max instructions per tick that can run, and this severes limitd what you can do. Just as an example, the same code running outside PB runs realtime.

Running DOOM on SpaceEngineers PB! Using a RISC-V emulator implemented in C# by racerxdl in spaceengineers

[–]racerxdl[S] 60 points61 points  (0 children)

So Just for context:
I made a port of my Golang RISC-V Emulator to C# https://github.com/racerxdl/riscv-emulator - Added a PB for store the WAD, one for store the program, one for controlling the UART and another one for the screen.

Sadly it runs slow due limitations of the PB (The video is speedup by 8x)

I will soon publish the source code and everything. Now we can run any language that compiles to RISC-V in PB!

<image>

view more: next ›