Release Notifications

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
L4rry
Posts: 239
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Release Notifications

Post by L4rry » Fri Oct 27, 2017 7:47 am

There's been a lot of activity recently around kernel optimizations and additions and even though I spot these things popping up on the forums and try to follow them best I can, I find myself lost really and afraid I might be missing out on cool new features I could potentially utilize for a future game or even and inspiration for a future game.

So I was wondering if it would be a good idea to start utilizing github releases to indicate major new features and fixes. So whenever a new feature is merged into master AND has been documented on the wiki, I suggest a new github release is created along with release notes and a link to the relevant wiki pages and forum topics.

What do you guys think? Maybe there is a better way to do this.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Release Notifications

Post by Jubatian » Fri Oct 27, 2017 8:06 am

I think the only major actual release was the improved Mode 3. I did some documentation work on it on the wiki, sure it could be continued as it was even more or less outdated compared to the original Mode 3.

Otherwise the followings are in the making:
  • Lee (D3thAdd3r) is working on streaming music, which is still very experimental (topic).
  • My new bootloader (topic) which is waiting for more feedback (testing mainly). The implications for games will be a new SD Card library using the bootloader's API of which an experimental demo is available in the topic.
  • I did some improvements on the inline mixer (post) which is waiting for testing. Implications for games would be a further kernel boost if they used the same inline mixer configuration.
  • A bugfix from me of the soft-reset funcion (GitHub issue), which has no implications for games, it only makes user experience smoother on the real hardware.
  • A proposed bugfix from me for a potential case which could possibly murder SD cards (GitHub issue), still needing some testing and feedback (topic). It has no implications for games.
  • CunningFellow is working on a new RLE mode (topic) which sure has potential, but I guess it will take a few months until it is ready for more serious experimenting.
Sure there are things going on, but most of them I think have no great implications for game programming (of these D3thAdd3r's streaming music and CunningFellow's RLE mode are things which actually open up new possibilities for games, the others rather polish the already existing system).

Halamix2
Posts: 16
Joined: Mon Jun 06, 2016 10:04 pm

Re: Release Notifications

Post by Halamix2 » Fri Oct 27, 2017 4:24 pm

What about Github releases plus changelog.txt with list of all changes grouped by release?

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Release Notifications

Post by Jubatian » Sun Oct 29, 2017 9:04 am

Halamix2 wrote:
Fri Oct 27, 2017 4:24 pm
What about Github releases plus changelog.txt with list of all changes grouped by release?
I think the Git commit history is just about that, and Git enforces maintaining it which is good. However there is a bit of clutter on the Uzebox master in this regard, sometimes I didn't particularly pay attention, sometimes others to have a nice clean commit history which could be browsed.

On Master probably the best would be squash-merging in finished changes with proper descriptions on it. Otherwise one-shot bugfixes and minor patches could also be OK (if it is a nice clean bugfix easily described). So possibly the best when someone works on something is forking it off, building the feature on a branch (not in the fork's master as it will mess up things bad as I experienced), then when it is complete and sufficiently tested, merge it in through a pull request. The merge then should be a squash-merge containing only the overall description of the new feature.

User avatar
L4rry
Posts: 239
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Release Notifications

Post by L4rry » Sun Oct 29, 2017 9:55 pm

I second squash merge on pull requests. But still. A commit comment is not a release note. It can't be expected for a newbie to trawl through a git history to figure out new features.

But you've actually put my mind at ease that all the current activities are still a work in progress so I guess the point is moot. Once things are stable and mature, they'll get documented and advertised :)

I think my initial concern originated with the last hardware board I bought from Ada Fruit and was totally surprised by the new SPI ram section. Never read about it before on the wiki.

Maybe I'm just an old sourpuss scared of change and should spend more time in the forums :p

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Release Notifications

Post by Jubatian » Mon Oct 30, 2017 6:43 am

L4rry wrote:
Sun Oct 29, 2017 9:55 pm
(...) It can't be expected for a newbie to trawl through a git history to figure out new features.
Why a newbia would want to see the "new" features if for him the entire console is new? :D

Maybe some export could be made of the commits later, for example into the Wiki. First I think organizing the master is important, to maintain a clean history in the future which is actually meaningful.

With the V 1.3.1 PCB I had the same problem recently when I gave one to my friends, that I couldn't find a schematic of that for them, although it isn't very difficult to figure it out. However the SPI RAM and the ESP8622 should certainly be documented better on the hardware side to make them easier to adapt (or hack onto existing older Uzeboxes in need).

I would also like to clean up the Video Modes section somewhat on the Wiki, to group modes by usability. I think for newcomers Mode 1, 3, 5, 6, 8, 9 and 90 should be exposed as these are reasonably easy to use, and could have their common use-cases. Mode 74 requires advanced programming. Mode 2 and 13 are useful but limited, needing consideration when deciding on them. The rest are specific or very experimental modes ("use them if know what you are doing"). Then later SPI RAM specific video modes might also arrive. I would also like to see JHHoward's 3D demo as a video mode, it definitely should be finished at some point as it is quite mindblowing to see this on the Uzebox (how something with just 4K RAM can do this?).

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Release Notifications

Post by uze6666 » Tue Oct 31, 2017 12:27 am

I couldn't find a schematic of that for them
Yep, indeed I forgot to update the download page with the latest revision. This is now corrected. :) It includes rev 1.3.2 of the PCB with the aforementioned fix to the SPI RAM.

User avatar
ry755
Posts: 154
Joined: Mon May 22, 2017 6:01 am
Location: California, United States

Re: Release Notifications

Post by ry755 » Tue Oct 31, 2017 2:42 am

uze6666 wrote:
Tue Oct 31, 2017 12:27 am
I couldn't find a schematic of that for them
Yep, indeed I forgot to update the download page with the latest revision. This is now corrected. :) It includes rev 1.3.2 of the PCB with the aforementioned fix to the SPI RAM.
Cool, I was wondering if that was going to be uploaded, I was curious how the Wifi chip and SPI ram were connected. Although I noticed there's a typo on number 3 in the word footprint:
3)New fottprint for SD card connector (see BOM)

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Release Notifications

Post by uze6666 » Wed Nov 01, 2017 4:04 am

Although I noticed there's a typo on number 3 in the word footprint:
Ha! Nice catch, fixed it, thanks. :)

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Release Notifications

Post by Jubatian » Wed Nov 01, 2017 8:03 am

uze6666 wrote:
Tue Oct 31, 2017 12:27 am
Yep, indeed I forgot to update the download page with the latest revision. This is now corrected. :) It includes rev 1.3.2 of the PCB with the aforementioned fix to the SPI RAM.
Great, thanks! I could give it to my friends to help them building their Uzebox!

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests