Post screenshots of stuff you're working on!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

«‹›203 »

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

hendersa posted:

Edit: I just pulled this monster off of my bookshelf and weighed it. It has 1342 pages and weighs 5.5 pounds.

This book is sitting to my immediate left (it got demoted from being a monitor stand, when I got a new monitor that has an adjustable base).

It has BIBLE PAGES. You know, those really thin pages that make a book weigh a bazillion pounds? It's like The Bible Of Game Math. It's beautiful. :love:

# ? May 8, 2016 20:05

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 21:59

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

munce posted:

The Moon:

No ring

# ? May 8, 2016 21:31

Neurion: Jun 3, 2013; The musical fruit
The more you eat
The more you hoot

Shalinor posted:

This book is sitting to my immediate left (it got demoted from being a monitor stand, when I got a new monitor that has an adjustable base).

It has BIBLE PAGES. You know, those really thin pages that make a book weigh a bazillion pounds? It's like The Bible Of Game Math. It's beautiful.

Aww, wish I had a physical copy of it. All's I got is PDFs and source code samples.

# ? May 8, 2016 23:14

ToxicSlurpee: Nov 5, 2003; -=SEND HELP=-; Pillbug

munce posted:

Looks like you've got your ui sorted. I always struggle with that. What are you making that in?

Yeah UI programming is always a pain. I end up redoing it at least once at some point.

I'm making it in Unity3D.

# ? May 8, 2016 23:49

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Munce needs to post an animated gif of every single spinning planet animated gif they've posted in this thread

# ? May 9, 2016 23:22

munce: Oct 23, 2010

Scaramouche posted:

Munce needs to post an animated gif of every single spinning planet animated gif they've posted in this thread

Only because you asked:

# ? May 10, 2016 08:02

~Coxy: Dec 9, 2003; R.I.P. Inter-OS Sass - b.2000AD d.2003AD

Man, I'm jealous that your dad sprung for the optional MPEG1 decoder card.

I can't play VCDs on our family computer and have to play the low res edition of Return To Zork. :smith:

# ? May 11, 2016 03:05

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Another video game model format viewer. This time, :darksouls:

If you have a PC copy of the game, you too can explore Dark Souls from the comfort of your web browser (Firefox and Edge tend to crash because there's "too much data", use Chrome).

http://magcius.github.io/dunky.js/

# ? May 11, 2016 06:53

IT BEGINS: Jan 15, 2009; I don't know how to make analogies

For now, a Python command line Twitter client:

Not very original, but I'm trying something vaguely novel architecturally. I'm implementing the code in a react + redux style, where I have some 'reducers' working on a singular state, and some containers + views that get state pushed to them and rendered. So far I'm liking how easy it is to test everything, even if I'm essentially re-implementing known tech.

I'm excited to try working with an Actor model and handling events here. It seems pretty simple - push all events into a queue and at each cycle pop them off, convert them into actions, and process as normal. I'm expecting implementing live tweet updates and stuff to be fairly simple (famous last words).

# ? May 11, 2016 09:13

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Did a little tinkering with Voronoi diagrams:

code:

p:  2 0N#32?w         / 16 random 2d points
c:  *<%+/{x*x}p-      / index of closest point
v:  c''t,/:\:t:!160   / voronoi diagram
,(;arne;v)

Euclidean Distance

Manhattan Distance

# ? May 13, 2016 03:12

Maide: Aug 21, 2008; There's a Starman waiting in the sky...

That code is super concise and looks like made-up, face-rolled-the-keyboard gibberish. It's like magic. :3:

# ? May 13, 2016 14:48

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Yeah, K has a tendency to look like that. Let's break it down.

Generating random points in screen space:

code:

p:  2 0N#32?w

Without parentheses, read K expressions from right to left; operators have strictly uniform precedence.

w is a pre-defined variable containing the width of the display. (generally 160).
Using x ? y as a binary operator means "choose x random things between 0 and y".
Using x # y as a binary operator with a list on the left means "reshape y according to the dimensions of x."
The sequence 2 0N is a 2-element list of numbers, with 0N being the literal form of not-a-number.
When reshape sees 0N as the first or last element of the shape, it treats that dimension as maximal.
p: stores the result of the right expression in a variable named p.

Step by step in the REPL:

code:

  w
160

  r: 32?w
116 41 117 33 135 87 151 108 98 12 10 74 19 5 146 126 72 103 89 31 40 151 31 103 56 4 152 109 25 114 156 17
  
  3 5#r
(116 41 117 33 135
 87 151 108 98 12
 10 74 19 5 146)

  2 0N#r
(116 41 117 33 135 87 151 108 98 12 10 74 19 5 146 126
 72 103 89 31 40 151 31 103 56 4 152 109 25 114 156 17)

Finding the index of the closest point:

code:

c:  *<%+/{x*x}p-

Using x - y as a binary operator means, unsurprisingly, subtract. In K, all arithmetic operators generalize to work on vectors or arbitrarily dimensioned structures.
The sequence {x*x} is an anonymous function. Since it references the name x only it is implicitly a function on 1 argument. This function squares its input.
The symbol /, in this context, is "over"- it's equivalent to "foldl" or "reduce" in other languages. Over consumes a function (+) immediately to its left.
The combination +/ calculates the sum of a list.
Using % x as a unary operator means take the square root.
Using < x as a unary operator is "grade up"- it generates a list of the indices of elements from x if they were sorted in ascending order.
Using * x as a unary operator is "first""- it takes the first element of a list.
The combination *< effectively means "the index of the minimum".
This whole expression could be read as "The index of the minimum of the square root of the sum of the square of our points minus�".
Since it has a dangling right argument, the expression stores a unary function in the variable c.

Step by step in the REPL:

code:

  p-10 30
(106 31 107 23 125 77 141 98 88 2 0 64 9 -5 136 116
 42 73 59 1 10 121 1 73 26 -26 122 79 -5 84 126 -13)

  {x*x}p-10 30
(11236 961 11449 529 15625 5929 19881 9604 7744 4 0 4096 81 25 18496 13456
 1764 5329 3481 1 100 14641 1 5329 676 676 14884 6241 25 7056 15876 169)

  +/{x*x}p-10 30
13000 6290 14930 530 15725 20570 19882 14933 8420 680 14884 10337 106 7081 34372 13625

  %+/{x*x}p-10 30
114.0175 79.3095 122.1884 23.0217 125.3994 143.4225 141.0035 122.2007 91.7606 26.0768 122 101.671 10.2956 84.1487 185.3969 116.7262

  <%+/{x*x}p-10 30
12 3 9 1 13 8 11 0 15 10 2 7 4 6 5 14

  *<%+/{x*x}p-10 30
12

Building our Bitmap

code:

c''t,/:\:t:!160

Using ! x as a unary operator is "iota"; it builds a vector of indices ranging from 0 up to but not including x.
The sequence /: means "each right", and the sequence \: means "each left".
To avoid getting bogged down in detail, simply understand that x f/:\: y takes the cartesian product of x and y, and applies the function f to each combination.
Using x , y as a binary operator joins x and y to form a list.
The symbol ' is "each". It maps the function on the left over every element of a list on the right.
The combination c'' "pushes" the function c onto each element of a matrix, giving us the index of the closest point to each position in the bitmap.

For purposes of explanation I'll pretend the right argument here is 3, rather than 160. Step by step in the REPL:

code:

 t:!3
0 1 2

  t,/:\:t:!3
((0 0
  0 1
  0 2)
 (1 0
  1 1
  1 2)
 (2 0
  2 1
  2 2))

  c''t,/:\:t:!3
(0 0 0
 0 0 0
 0 0 0)

Drawing the Bitmap

code:

,(;arne;v)

In iKe, you can draw an image by simply making the last expression in your program return a list of tuples. If a tuple has 3 elements, they're interpreted as the position at which to draw an image, a palette, and a bitmap, respectively.
The variable arne contains a predefined list of colors based on Arne's 16 color palette. iKe has a number of these built in to ease experimentation. The contents is just a list of DOM color codes:

code:

("#000000"       
 "#9D9D9D"       
 "#FFFFFF"       
 "#BE2633"       
 "#E06F8B"       
 "#493C2B"       
 "#A46422"       
 "#EB8931"       
 "#F7E26B"       
 "#2F484E"       
 "#44891A"       
 "#A3CE27"       
 "#1B2632"       
 "#005784"       
 "#31A2F2"       
 "#B2DCEF"       
 "rgba(0,0,0,0)")

If no position is specified, the bitmap is drawn centered on the screen.
The leading , means we're returning a 1-element list of tuples.

� probably still gibberish, hunh?

# ? May 13, 2016 16:42

taqueso: Mar 8, 2004

IJ, you are a treasure. Thanks for that detailed explanation.

# ? May 13, 2016 17:44

redleader: Aug 18, 2005; Engage according to operational parameters

Internet Janitor posted:

� probably still gibberish, hunh?

I can see why APL-ish languages are described as "write only" :v:

Thanks for taking the time to write that up. How hard was it and long did it take you to write that?

# ? May 14, 2016 04:37

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

The program? Just a few minutes.

The step-by-step explanation? Easily half an hour.

I don't really expect many people who are not me to ever use iKe, but it makes me really happy- I've never had an environment where it was so fun and easy to tinker with and share little graphics programming experiments and animations. There's almost no boilerplate to write and I can dash off ideas nearly as quickly as they form in my head.

# ? May 14, 2016 04:47

evilentity: Jun 25, 2010

This K thing is loving nuts.

Anyway, prototyped a thing:
https://www.youtube.com/watch?v=VDTil3bhxHQ
Dynamic async generation of 8x8 tiled tiles with noise thing from base map. A bunch of semi transparent circles on top of each other. Super junky but will be useful with some luck!

evilentity fucked around with this message at 23:52 on May 15, 2016

# ? May 15, 2016 23:49

ErIog: Jul 11, 2001

This doesn't really look like anything special, but it's the culmination of 2 months worth of work/study.

It started life as a toy software renderer implemented in 100% Ruby based on this tutorial. Ruby is not the best choice at all, but I needed to learn it for my job and I learned a lot about profiling and optimizing Ruby code. I used no libraries, and implemented everything from BMP writing to triangle filling to vectors to matrix math myself. Went from 45 seconds per frame to 1.5 seconds per frame at 384x384 resolution over the course of a few weeks.

I then started extending my Ruby with C extensions to try to get more performance gains. I got it to go from 1.5 seconds per frame to about 350 milliseconds per frame, but by the end of it there was almost no Ruby code left. So I reversed the paradigm from C extension of Ruby to a Ruby interpreter running in C. The main loop, model loading, and PNG loading were handled in Ruby. All the rendering happened in C. I got down to 300 milliseconds per frame this way.

I then brought SDL into the equation so I could do more than just spit out a BMP, and for about a week I had a C program spawning an SDL window rendering a model with assets loaded through Ruby. I could finally do stuff like simple animation, albeit at terrible FPS.

Feeling I had learned all I needed to learn from my foray into software rendering, I converted all the remaining Ruby code over to C in preparation for moving to OpenGL 2.1. Doing the model loading in C took me like half a day to write, and then another 2-3 hours to figure out how to make it load models with no UV's properly. I cheated and used a library to load PNG's, and I don't feel bad about it at all. From there it was only about 2 hours worth of work to get back to where I had been with my software renderer, but running at ridiculous FPS because drawing 1600 tri's just ain't no thing for a real GPU.

Last weekend I moved away from using my own C vector/matrix library to GLM. That sounds trivial, but GLM is C++ so I had to move my project over to C++-conforming C which produced zillions of errors about char* and took a while to figure out. Yesterday I moved from doing glVertex3f calls manually over to using Vertex Array Objects. Today I studied model, camera, and projection matrices which finally allowed me to put in a user-controllable camera.

I've made 2D games before, but I always felt like I could never do anything in 3D myself because the math was just beyond what I thought I'd ever be able to comprehend. Turns out if you just bang your head against it and work your way up implementing absolutely every piece of it yourself everything starts to seem really obvious.

# ? May 17, 2016 08:35

Jewel: May 2, 2009

ErIog posted:

This doesn't really look like anything special, but it's the culmination of 2 months worth of work/study.

It started life as a toy software renderer implemented in 100% Ruby based on this tutorial. Ruby is not the best choice at all, but I needed to learn it for my job and I learned a lot about profiling and optimizing Ruby code. I used no libraries, and implemented everything from BMP writing to triangle filling to vectors to matrix math myself. Went from 45 seconds per frame to 1.5 seconds per frame at 384x384 resolution over the course of a few weeks.

I then started extending my Ruby with C extensions to try to get more performance gains. I got it to go from 1.5 seconds per frame to about 350 milliseconds per frame, but by the end of it there was almost no Ruby code left. So I reversed the paradigm from C extension of Ruby to a Ruby interpreter running in C. The main loop, model loading, and PNG loading were handled in Ruby. All the rendering happened in C. I got down to 300 milliseconds per frame this way.

I then brought SDL into the equation so I could do more than just spit out a BMP, and for about a week I had a C program spawning an SDL window rendering a model with assets loaded through Ruby. I could finally do stuff like simple animation, albeit at terrible FPS.

Feeling I had learned all I needed to learn from my foray into software rendering, I converted all the remaining Ruby code over to C in preparation for moving to OpenGL 2.1. Doing the model loading in C took me like half a day to write, and then another 2-3 hours to figure out how to make it load models with no UV's properly. I cheated and used a library to load PNG's, and I don't feel bad about it at all. From there it was only about 2 hours worth of work to get back to where I had been with my software renderer, but running at ridiculous FPS because drawing 1600 tri's just ain't no thing for a real GPU.

Last weekend I moved away from using my own C vector/matrix library to GLM. That sounds trivial, but GLM is C++ so I had to move my project over to C++-conforming C which produced zillions of errors about char* and took a while to figure out. Yesterday I moved from doing glVertex3f calls manually over to using Vertex Array Objects. Today I studied model, camera, and projection matrices which finally allowed me to put in a user-controllable camera.

I've made 2D games before, but I always felt like I could never do anything in 3D myself because the math was just beyond what I thought I'd ever be able to comprehend. Turns out if you just bang your head against it and work your way up implementing absolutely every piece of it yourself everything starts to seem really obvious.

I like this writeup! It's really good to feel like you solidly know the inside and out of why and how things work like they do.

# ? May 17, 2016 10:40

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

ErIog posted:

Much respect. You've earned your hardcore self-taught wings. There should be, like, pins we can hand out for this.

EDIT: Meanwhile, I'm presently up to my neck in C++, and actually thinking "oh god I think I have to go back to C# this is taking too long." I'm thinking of jumping ship back to Unity, after we ran a test on the UE4 contract we're on and got a clear sign of how much faster development in Unity goes.

Shalinor fucked around with this message at 17:46 on May 17, 2016

# ? May 17, 2016 16:51

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Shalinor posted:

Much respect. You've earned your hardcore self-taught wings. There should be, like, pins we can hand out for this.

I'm personally very entertained. It was all "Hey, I need to learn Ruby!" [does a bunch of typing] "How the gently caress did this turn into C?" It's like the Midas Touch of C or something.

# ? May 17, 2016 17:27

evilentity: Jun 25, 2010

ErIog posted:

https://github.com/ssloy/tinyrenderer/wiki

I really need to do this, cant wrap my head around all this 3d stuff.

# ? May 17, 2016 22:04

Schmerm: Sep 1, 2000; College Slice

Neurion posted:

I've been toying with the idea of writing a GameBoy Color emulator for DOS, and as a stepping stone along the way, I've been working on code that allows me to use SuperVGA video modes in a protected-mode program. As practice, I've updated my FM-synth based MIDI player and added a piano roll style visualization, using a 640 x 480 x 256 color mode. A lot of work went into this, especially the code for drawing text to the screen as fast as possible. My original version of the code would draw character by character, line by line (finishes drawing an entire character before moving to the next character). This turned out to be slower than the current version, which instead draws line-by-line, character-by-character (draws a 1-pixel high section of the entire row before moving down to the next). The latter worked out faster due to the fact that I can take advantage of the 32-bit bus size of the 386/486 running in protected mode, allowing me to write 4 pixels in a single MOV, among other reasons. You can review the code for a better idea, maybe.

Anyways, the next major change was to de-couple the MIDI player logic from the Programmable Interval Timer (PIT). Originally the MIDI player wrote directly to the PIT registers and handled the PIT interrupt, monopolizing use of the only free timer for itself. Now a Timer object sits between the MIDI player (and the new visualizer code) and the PIT, keeping track of a number of sub-timers and allowing other objects to query the states and elapsed ticks of these sub-timers.

Finally, the last major change was the addition of the visualizer itself. Originally I wrote a version that used the 80 x 50 text mode to display the visualization. It was very speedy, but had the limitations of low resolution (updated at 30 Hz), scrolling too quickly (even at 30 Hz), and only showing a subset of the 128 keys MIDI files support. I then wrote a different version that makes use of SuperVGA to allow me to show the entire key range as well as provide a higher resolution (60 Hz) and scrolling at an acceptable speed. In order to speed up the visualizer code, I avoided moving the entire visualizer graphic each frame, and would instead record what keys change their state on each frame to minimize the amount of drawing. Effectively, it adds color to the leading edge of a note and removes color from the trailing end on each new frame. Here's the code for the visualizer.

I recorded a new demo of the MIDI player to show off the visualizer:
https://www.youtube.com/watch?v=AWa4h0RiY8E

And here's the GIT for the entire project, if anyone's interested in my messy code.

Which C++ compiler are you using? Does it not come with <cstdint>, forcing you to typedef all your integer types yourself in globals.h?

# ? May 17, 2016 23:07

Schmerm: Sep 1, 2000; College Slice

hendersa posted:

After a day or so of debugging with my scope, I have the SNES gamepads now interfacing with my BeagleBone Black via the BBB programmable realtime units (PRUs). The PRUs are microcontroller-like processors, built into the main CPU, that can share memory with the main CPU and execute each instruction in 5ns (unless you're hitting main memory, which takes more like 20ns for the access). I applied some 3rd-party kernel patches to enable userspace I/O (UIO) access to the PRUs on the 3.14 kernel. Once I was able to write some C code to upload firmware to a PRU and get it running, I screwed around with my scope and monitored memory from userspace to debug my firmware code and get the gamepad states back from the PRU via shared memory.

https://www.youtube.com/watch?v=rLUWo8wX8Jc

I'm now bitbanging the SNES gamepad protocol via four GPIOs, and it takes no resources from the main CPU to do it. I just look at a single 32-bit memory location (mmap'd into my userspace process) that represents the current state of the two gamepads. I can check their state anytime by just dereferencing a pointer. This is a big deal for me, since it means the controls won't get "sloppy" when the CPU gets taxed by the emulators.

Does your 32-bit register store just the latest/current value that the PRU put in there, and is overwritten independently of the CPU checking it? Meaning, is it possible for the CPU to ever 'miss' an update because it spent too long between checking this register?

# ? May 17, 2016 23:15

Neurion: Jun 3, 2013; The musical fruit
The more you eat
The more you hoot

Schmerm posted:

Which C++ compiler are you using? Does it not come with <cstdint>, forcing you to typedef all your integer types yourself in globals.h?

I'm using Open Watcom C/C++, and I like to typedef all my integer types myself :shrug:

# ? May 18, 2016 00:14

hendersa: Sep 17, 2006

Schmerm posted:

Does your 32-bit register store just the latest/current value that the PRU put in there, and is overwritten independently of the CPU checking it? Meaning, is it possible for the CPU to ever 'miss' an update because it spent too long between checking this register?

Yes, yes, and yes.

The 32-bit value is placed in memory shared between the PRU and the CPU. Since it is a single 32-bit word, it is fetched in one memory bus request and can't be corrupt by the CPU reading memory at just the right moment when the PRU updates it. Typical desktop computer event handing generates events on transitions. If a key is pressed or released, an event is generated for that transition and added into an event queue. When you get around to processing the queue in your event loop, you run through all of the queued events and act on them. This is a different model: you keep a copy of the last state sitting around and you look at the new state when you want. XOR the two 32-bit values together to see what bits have changed. Update those buttons accordingly and then make the new state the old, cached state for the next comparison.

On the actual hardware, games are checking the state of the gamepad register once during each 50/60 Hz frame. I may not be checking it at that exact frequency and may miss some, but that is OK. It will still have far less latency than a USB gamepad going through the kernel USB subsystem, joystick subsystem, back to userspace, into the event queue, and then being acted on by the emulator. If someone was, say, pressing and releasing a button at exactly 30Hz, then I probably wouldn't catch all 30 button presses if the CPU is being stressed by the emulator. But, I bet I'd see more button presses than I would if you did the exact same thing with a USB gamepad. The SNES gamepad takes care of debouncing and such, so I only have to worry about the bits that it reports back to me (which I then store in the shared memory).

# ? May 18, 2016 14:04

Luigi Thirty: Apr 30, 2006; Emergency confection port.

hendersa posted:

I HEARD THE CALL. I AM HERE.

Compiler: Watcom with DOS Extender
DOS 21h interrupt functions: Interrupt list
Free version of Abrash's Graphics Programming Black Book
55ms timer interrupt: RTC interfacing
Z80 instruction set: Here
Sound Blaster programming: Guide here

HOORAY! YOU WILL LEARN MUCH.

Edit: I just pulled this monster off of my bookshelf and weighed it. It has 1342 pages and weighs 5.5 pounds.

Making some DOS game in Watcom is something I've wanted to do since I got a shovelware game CD and a bunch of books I didn't understand when I was like 9. I should grab this and make the dinky thing I've always wanted.

Or maybe I should finish my C# NES emulator! I have a working CPU core and I can render one frame of background at approx 0.01 FPS before everything explodes.

In the meantime, my first venture into F#: I bought the Neatest Little Guide to Stock Market Investing and it came with a spreadsheet in the back. Unfortunately the data that you need to fill in the spreadsheet for individual stocks isn't really in one place. So I made it available in one place thanks to Quandl:

Luigi Thirty fucked around with this message at 01:08 on May 22, 2016

# ? May 21, 2016 23:08

MrMoo: Sep 14, 2000

Consider you are only showing the consolidated market price, you should be able to get the price on each market venue, with some people preferring the primary exchange for NYSE. It quickly becomes a beast of data.

# ? May 22, 2016 01:53

Luigi Thirty: Apr 30, 2006; Emergency confection port.

MrMoo posted:

Consider you are only showing the consolidated market price, you should be able to get the price on each market venue, with some people preferring the primary exchange for NYSE. It quickly becomes a beast of data.

Currently I'm just grabbing whatever the closing price value is set to in this database since I've already got a library hooked up for reading from there. It also needs to be able to do annual instead of quarterly data, let you see the rest of the provided fundamentals (plus whatever else I can calculate), etc...

# ? May 22, 2016 02:17

Switzerland: Feb 18, 2005; Do what thou must do.

And right-align your numbers holy argh :stonk:

# ? May 22, 2016 02:51

MrMoo: Sep 14, 2000

Luigi Thirty posted:

Currently I'm just grabbing whatever the closing price value is set to in this database

I have access to everything but :effort:

Here's the basic page for Apples, check out all the tabs

Surprisingly not a lot of it is accessible programmatically, a mountain of hacks upon hacks.

MrMoo fucked around with this message at 03:11 on May 22, 2016

# ? May 22, 2016 03:07

Luigi Thirty: Apr 30, 2006; Emergency confection port.

MrMoo posted:

I have access to everything but

Here's the basic page for Apples, check out all the tabs

Surprisingly not a lot of it is accessible programmatically, a mountain of hacks upon hacks.

I wish I had that kind of visualization! I've got about a hundred indicators I can get through the API that I'm using. I just need to, uh, figure out how to interpret most of it.

# ? May 22, 2016 04:06

Factor Mystic: Mar 20, 2006; Baby's First Post-Apocalyptic Fiction

Luigi Thirty posted:

Or maybe I should finish my C# NES emulator! I have a working CPU core and I can render one frame of background at approx 0.01 FPS before everything explodes.

Is this project open source? I'm curious for curiousity's sake.

# ? May 22, 2016 20:35

Luigi Thirty: Apr 30, 2006; Emergency confection port.

Factor Mystic posted:

Is this project open source? I'm curious for curiousity's sake.

Sure if you want a bunch of PPU code that doesn't work! I wrote the 6502 core for an Apple I emulator that I wrote that does work but I never finished adapting it for NES emulation.

https://github.com/Luigi30/nessarabia

# ? May 22, 2016 22:57

MrMoo: Sep 14, 2000

Luigi Thirty posted:

I wish I had that kind of visualization! I've got about a hundred indicators I can get through the API that I'm using. I just need to, uh, figure out how to interpret most of it.

It's all D3.js stuff and probably only works in Chrome, the desktop app uses CEF for new stuff and Trident for old content. A similar system is Open F2.

# ? May 23, 2016 01:22

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

I made a thing while I was working on a particle system for a game:

You have to see it in real time to really appreciate it:
http://matt.stumpnet.net/paint/

# ? May 24, 2016 18:24

lord funk: Feb 16, 2004

HappyHippo posted:

I made a thing while I was working on a particle system for a game:

You have to see it in real time to really appreciate it:
http://matt.stumpnet.net/paint/

oooooooooh very nice.

# ? May 24, 2016 20:13

crab avatar: Mar 15, 2006; iÅ§ KÃ«3Å, cÄ§ gÃ¸Ã i- <Ecl8

HappyHippo posted:

I made a thing while I was working on a particle system for a game:

You have to see it in real time to really appreciate it:
http://matt.stumpnet.net/paint/

This is really cool :weed:

# ? May 24, 2016 21:01

Factor Mystic: Mar 20, 2006; Baby's First Post-Apocalyptic Fiction

Luigi Thirty posted:

Sure if you want a bunch of PPU code that doesn't work! I wrote the 6502 core for an Apple I emulator that I wrote that does work but I never finished adapting it for NES emulation.

https://github.com/Luigi30/nessarabia

This is a 404. Is the repo private or something?

# ? May 24, 2016 23:26

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

Thanks guys, how was the performance? Did the framerate drop at any point?

# ? May 25, 2016 01:04

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 21:59

Aurium: Oct 10, 2010

HappyHippo posted:

I made a thing while I was working on a particle system for a game:

You have to see it in real time to really appreciate it:
http://matt.stumpnet.net/paint/

I really want to stir this with my mouse.

# ? May 25, 2016 04:12

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

«‹›203 »