-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ideas for project setup ? #1
Comments
That all sounds good to me. 👍 I thought about deployment. Github supports GitHub Pages which is essentially source control for HTML pages. Using GitHub Pages for this repo, we could perhaps deploy the web version directly from here. 🤔 |
Oh yes, that could work 🤓... when it allows us to upload .wasm .js and .data files. |
@mithrendal and @dirkwhoffmann Gentlemen, first of all congrats to this really cool project! :-) About this:
Yes, you can use GitHub Pages to serve WebAssembly apps. I am actually using GitHub Pages including the built-in Jekyll static site builder to host my own WebAssembly/WebGL Emscripten app. For using GitHub Pages Just create a branch called "gh-pages" in your repo and check-in the .wasm, .js and .data files there. Activate the branch in the repo's "GitHub Pages" settings and you are done. Also, just in case you haven't seen this one, yet and as soon as you want to experiment with your own "GUI": This minimal Emscripten Shell file (link) is a better starting point for creating your own GUI than the bloated standard Emscripten shell and you can add it to your build using the |
Hi sy2002, thanks for your feedback it is very welcomed ... 😊
Thats sounds pretty cool.😎 We should definitely evaluate that ...
Thanks for the hint 😍!!! Thats exactly what I already did, it is just not yet in the master, head to the dev branch for a review. Although I am still learning about gnu-makefiles, I think I achieved some optimisations to it ... e.g. all the object files are generated now in a dedicated "obj" folder... I am currently struggeling at the fullscreen topic.🧟♀️ (not commited/pushed in yet) Rendering directly via surface with manual pixel modification works fine. The render texture thing still gives me headaches😷... see here make fullscreen work |
to try out github pages I followed the advice of @sy2002 and actived it in the settings like he said. I had to fork the repo though to try this out because I can not go into the settings of this repo to activate because dirk is the owner ;-) as a test it works very well see here ... https://mithrendal.github.io/virtualc64web/vC64.html just drag the 4 rom files into the vc1541 .... and it will copy them to local storage for subsequent visits to the site ... @dirkwhoffmann I think we should activate github pages in this repo ... what do you think ... how do we organise this ... a special branch maybe like sy2002 said ? |
Just a small sidenote: Normally you would empty the gh-pages branch completely and just add the files necessary for Jekyll and other web contents. Currently your gh-pages branch seems to be fully crowded and a clone of main or dev. Here is an example of what I mean by "empty" and "just web and Jekyll stuff" :-) |
Oh yeah ... whats jekyll ? ... hang on I am looking into the Jekyll stuff ... In fact super cool would be an automatic builder, which builds the gh-pages branch contents when for example branch dev receives a push ... @dirkwhoffmann is this done with the travis thing ? otherwise I just read that github has the option to only make master/docs folder the root of the github pages site... hmmm ... what is the "normal" workflow for publishing to gh pages ? maybe I still don't get the meaning of this special gh-pages branch ... there must be something more magic in it right ? |
I can only see this two solutions ... we add a "publish" target to the makefile
this would then only copy all necessary files to run VirtualC64web into the /docs folder ... then we had to alter the github pages of this repo to but maybe there is some more magic in the gh-pages branch which I don't see at the moment ? Or another approach would be to delete all the stuff in gh-pages branch and clone it parallel to the for example branch /dev cd .../some_workspace this would result in we could alter the "publish" command in the makefile in 64dev that it copies the necessary files to the gh-pages branch ...
this would copy the the necessary files to the gh-pages branch then with
we could update the gh-pages branch ... any thoughts ? |
I did go with now it starts up when you call https://dirkwhoffmann.github.io/virtualc64web/ be sure to put it onto your iPhones homescreen 😍 |
Works like a charm. Very cool 😎. |
I have committed the original unmodified C64 emulator dir from virtualC64 into the master of the virtualc64web. 🥳
I did chose to not commit the last working modded C64 with running octopus into master by intention. Because I think we need to have the history of patches I already have applied (without git ) to the precious original core. I feel this is important because in case of any problems (my toxic mach_time_functions replacments, etc..😷😷😷) we can trace all modififications made to it and improve them.
Next I have made a new branch dev where I have commited all mods to C64 with running octopus. I am still at it and it is not ready to merge into master. Like to finish and cleanup the dev branch in the coming days. (Also I used a wrong author-name "Baba" 😱at one single commit in the dev branch, ... git username was wrong in git config in one of my machines ... also like to repair this.)
In github you can already compare dev to master to see the current applied mods. I also made a v0.0 Release so in future we can always compare all coming mods to the baseline version v0.0.
The text was updated successfully, but these errors were encountered: