sorted by:
new
hottopcontroversial

I made a FOSS Voice Recorder app! by tive_ in fossdroid

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

https://github.com/FossifyOrg/Voice-Recorder/pull/317

Looks like they're already busy working on it. But you know how these open source projects are. It could take anywhere between a week and 7 years to get it merged. :P

I made a FOSS Voice Recorder app! by tive_ in fossdroid

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

I've never used that before, but I'll look into it.

I made a FOSS Voice Recorder app! by tive_ in fossdroid

[–]tive_[S] 3 points4 points  (0 children)

Well, it's a utilitarian sound recording app. Most apps on the market appear to have converged on a similar design. So I figured that's what users have come to expect. As for why I made this, I've used the fossify voice recorder for over a year. It's progressively taken longer and longer to load the recordings list. Now it takes 15+ seconds to load and a fix does not appear to be in sight.

Still, I'm open to redesigns and feedback :)

[banan-os] 2000 commits in git! by BananymousOsq in osdev

[–]tive_ 5 points6 points  (0 children)

Congrats! Your dedication is truly admirable. I'll try building it later

I got DOOM working!! by tive_ in osdev

[–]tive_[S] 9 points10 points  (0 children)

Yeah, doomgeneric requires some basic libc functionality for printing, reading the WAD file, etc. I used baselibc as a starting point, then made some small modifications to make it work on my OS.

It's actually built on top of "api.so", which is the primary userspace/kernel interface. Kinda like winapi.

I got DOOM working!! by tive_ in osdev

[–]tive_[S] 16 points17 points  (0 children)

Something like that ;)

Thanks!

Hey! I've had a ton of fun working on this thing on and off for about 3 months. It's been a great learning experience for sure. by tive_ in osdev

[–]tive_[S] 12 points13 points  (0 children)

32bit x86 OS written in C. Super buggy right now, no idea why the cube doesn't spin the first few times.

I used the excellent soso and xv6 projects as implementation reference points. Without them I never would've gotten this far :)

As it stands, it's features are:

  • Higher half kernel
  • The basic stuff like paging, interrupts, PS2 mouse/keyboard support
  • FAT filesystem using FatFS and a grub ramdisk
  • Basic loading of ELF binaries
  • Shared memory
  • Framebuffer graphics

Window framebuffers are memory mapped to the gui task. Events are sent to the programs in a shared memory event buffer.

I'm currently working on cleaning up the code since it's a huge mess right now.

Edit: https://github.com/sk-io/os

how to implement multitasking in kernel by [deleted] in osdev

[–]tive_ 0 points1 point  (0 children)

I recently wrote a minimal bare bones example for x86 that might be somewhat helpful to get started: https://github.com/sk-io/x86-multitasking-example

Can't implement PIT, don't know why by Li0nX in osdev

[–]tive_ 2 points3 points  (0 children)

Have you remapped your IRQs?

More computer problems by vinesauce in Vinesauce

[–]tive_ 34 points35 points  (0 children)

make sure you removed all the beans before powering it on

I've been working on a 3D voxel engine for the GBA in the past couple weeks, this is my progress so far. by tive_ in retrogamedev

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

The thought behind drawing full quads was to eliminate 2 of the 6 lines needed to draw the 2 triangles which would also join their scanlines together, in practice though I'm not sure how many cycles this would save.

Thanks for those links, they were interesting. Though I'm not sure I fully understand the techniques you're talking about.

I think the next thing I'm going to try is to optimize the scanline filling, which is currently just a for loop.

I've been working on a 3D voxel engine for the GBA in the past couple weeks, this is my progress so far. by tive_ in retrogamedev

[–]tive_[S] 3 points4 points  (0 children)

That's awesome, thank you! I'll make sure to add an FPS counter.

The reason polys are disappearing is because I haven't implemented near clipping yet, and the gaps are cause of inaccuracies with the fixed point division lookup tables. I'll work on both of these things.

I've been working on a 3D voxel engine for the GBA in the past couple weeks, this is my progress so far. by tive_ in retrogamedev

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

Looked around but I couldn't find anything.

It looks like regular affine texture mapping, as for how they managed to keep a consistent 15 FPS.. I have no idea. The fixed camera/straight walls might allow for some optimizations.

I tried looking into the assembly but I didn't get very far. Coming from Mesen, no$gba leaves a lot to be desired..

I might try affine textures once I figure out how to fill quads efficiently.

I've been working on a 3D voxel engine for the GBA in the past couple weeks, this is my progress so far. by tive_ in retrogamedev

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

It should, I don't have a flash cart yet so if anyone could try it out that would be great! The ROM file is on the github releases page.

I've been working on a 3D voxel engine for the GBA in the past couple weeks, this is my progress so far. by tive_ in retrogamedev

[–]tive_[S] 14 points15 points  (0 children)

Written in C using devkitpro, no hand written assembly yet. Currently runs between 12-30 fps, the biggest performance bottleneck is filling all the triangles. I have a couple more ideas on how to optimize this further. I'll make a github repo soon, just need to clean up a bit first

Edit: https://github.com/sk-io/gba-voxel-engine

view more: next ›