Editing BinaryData:: workflow

#1

Hi there,

Have a few questions regarding BinaryData.

  1. Anyone care to share their workflows with how to (quickly/conveniently) rebuild BinaryData. E.g. I have a built shader, then I edit the shader, what now?

I sense there’s multiple ways/tricks that one might use so there may be no right/wrong answer to this.

I can be certain that my current way is wrong though - which is to untick the file’s Binary Resource checkbox in Projucer, build (to failure), then re-tick the checkbox.

  1. Is there a way to access a BinaryData file at runtime on iOS.

E.g. on mac, the BinaryData file is in some Asset folder and you can just browse your way to it.

But on iOS filesystem you can’t navigate to the originating Asset folder located on the osx filesystem.

Many thanks for the help.

0 Likes

#2

Anything marked as “Binary Resource” in projucer gets added to BinaryData.h/cpp, which gets compiled.

you access them in your code by #include "BinaryData.h" and then BinaryData::someGraphic_png or whatever.

If you have shader files you’re trying to use in your project, you should add them as an Xcode resource (or as a custom xcode resource folder), and then use the File::getSpecialLocation calls to load them as regular data. You could do some timer-based polling of the folder to check for updates. Take a look at how the 2D OpenGL demo works, the one that lets you edit the shader in the program. Basically scan for differences once-per-second and reload/recompile the shader in realtime…

1 Like

#3

I think you misunderstand me. I don’t need to know about changes at runtime. I’ll try to rephrase as simple as I can.

If I want to make a change to a .cpp source file, I edit the source file, I click build, then my IDE compiles the change that I made.

If I want to make a change to a shader file (which is loaded as BinaryData), I edit the shader file, I click build, but my IDE compiles without using the changes I just made.

My question is more of a workflow thing, I was hoping there was an answer that involves a correction in the way I’m working, OR if a more convenient solution requires integrating into the codebase, I’m hoping it’s not as intrusive as building a dedicated polling mechanism.

0 Likes

#4

Don’t load your shader via BinaryData.h/cpp. Load it as a regular text file via the File class. Set up that system I mentioned scanning a file/directory for changes so you can edit your shader while your app is running. this way you don’t have to keep recompiling to view changes to your shader.

It’s super easy to add a timer to your class and look in File::getSpecialLocation( File::SpecialLocation::ApplicationDirectory ) or whatever its called to see if any .shad (or whatever type) files have been changed since they were last loaded. You got this! embrace the challenge.

2 Likes

#5

This won’t work in iOS though. I have already implemented your solution in the app that you opened an issue on my github in - LiveShaderPalette.

I’m not sure your suggestion is a challenge. Being an intrusive mechanism I’m considering it as the easy way out.

0 Likes

#6

How about this:

  • load the BinaryData into a MemoryBlock
  • use the MemoryBlock for rendering instead
  • Add a TextEditor on the fly, similar to LIVE_BUILD_CONSTANT
  • this changes the MemoryBlock, and you should be able to see the changes in live

…once you are happy with the result, copy the text back to Projucer (iOS will be a pain thanks to sandboxing…)

1 Like

#7

admittedly i have no idea what LIVE_BUILD_CONSTANT is/does (dw I’ll look this up myself) but this sounds like a good direction where I can macro it out fairly easily in a release build. Thanks for the easter eggs

0 Likes

#8

it doesn’t work on ios, sadly, because ios apps are full screen…

0 Likes

#9

It doesn’t have to be a new window, can’t you just add your textEditor as overlay component in a corner?

For reference: JUCE_LIVE_CONSTANT :slight_smile:

1 Like