nesdev.com

I'm finding some time to work on NESICIDE and I'm wondering if there are any users or potential users that have any concerns/requests?

I've heard and am working to address build and deployment of packages for Windows, Linux, and OSX.

I've made some improvements to the MFC HLE supporting the Qt Famitracker. Currently looking into a bug preventing Key Repeat checkbox check'iness.

I've started working on improvements for the VICE/C64 emulator connection and support for C64 projects and running/debugging C64 PRG files [and disk images]. I know this isn't specific to the NES community, but I am not happy with how the IDE/emulators are tied together at the moment.

What bugs prevent you from using NESICIDE [besides build/deploy madness]?
What features aren't there that prevent you from using NESICIDE?

Yes, I recognize that IDEs aren't for everyone.

I appreciate any feedback! PM or public. Thanks!

I've yet to find the time to properly try nesicide out. Gotta finish some projects first. But toggle switch is using nesicide for the compo entry we're doing.

does ft qt incorporate sunsoft 7b support these days?

_________________
http://www.frankengraphics.com - personal NES blog

I don't know about Sunsoft 7b [typo?], but Sunsoft 5b appears to be supported only in _DEBUG builds of Famitracker 0.4.6.

I am interested in obtaining the source for Famitracker 0.5.0, which I think might have it finished, but jsr has so far been unresponsive.

Public releases of JSR FamiTracker appear to have stalled. HertzDevil's 0CC-FamiTracker is still being actively developed, and it supports 5B. What would it take to adapt Qt-MFC to 0CC-FT?

If OCC-FT and JSR-FT are the same source basis at some point in the past [which I believe they are but I hadn't been following OCC to closely], it shouldn't take too much effort to get OCC in Qt. I'd just need the source. The whole point of the Qt-MFC layer is the source should air-drop as-is. Granted it's not absolutely perfect but it hasn't required too many tweaks as Famitracker went from 0.4.1 to 0.4.6.

EDIT: Found/cloned GitHub source. Will do a comparison and see what's what.

huh, yeah sorry, i have an excellent track record of confusing digits.

Anyway, the reason i'm asking is that i could see that as a good project getting into nesicide in the future (i'm thinking earliest summer 2018 given my to do list) to get more closely acquinted with both this synth chip and nesicide itself, if support was present. Maybe do a ROM music "record" or a very simple space shooter accompanied by the same.

_________________
http://www.frankengraphics.com - personal NES blog

howdy,

i've been using NESICIDE to make a pretty sizable project for the 2017 compo ( viewtopic.php?f=33&t=16785 ), and one problem i encountered multiple times was with using multiple source code files. it's been a while so i may have done something wrong or maybe i am slightly mis-remembering, but basically:

if you have multiple files, the 'extra' files (anything beyond the first one) don't seem to properly update when the project re-compiles. for example, if i move all my zero page declarations into a separate file, i can't actually make any edits to that new file - they simply don't take place. again, maybe i was doing something wrong?

other than that, i think more than new features, NESICIDE needs better documentation (again, maybe i have missed something). for example, the first time i opened tepples' HELLO WORLD program and tried to run it, i compiled it, then pressed play on the emulator. nothing happened! i had failed to load the ROM. i stumbled about until accidentally discovering i needed to load the ROM first.

i had a similar issue adding extra graphics banks - the functionality is there, but i couldn't find a documented way to do stuff, so i just tried a bunch of things until one of them worked. worse, i have no idea which method eventually worked so i'll need to repeat the process next time i need to add more graphics.


all of these complaints aside, NESICIDE has been essential to me! i'm a pretty technically minded person who has been hobby programming for 20 years, and i was having a lot of trouble getting into other toolsets. NESICIDE was exactly what i needed to kickstart development in a way that didn't feel completely janky. so, thanks so much!

Well shit. Roadblock #1. C++17 versus clang on OSX.
I know I should praise people that keep up with the latest trends in language development (Swift, anyone?) but using features from a standard that isn't finalized?! Yikes!

Does GCC support the features?

In OSX, gcc and clang seem to be intertwined.

I am looking into upgrading LLVM to 5.0.0 which apparently supports all of the draft C++17.

This is great to hear. I've long wanted to give NESICIDE a try, but I've never been able to successfully build it on my Mac, and that's where I do all of my NES dev work.

Have you tried the DMGs here?

A user on the FamiTracker users' Discord server pointed me to this Android NDK issue. Comments to that issue imply that Clang's support for C++17 features is even better than GCC's. Is it just that Xcode has an outdated version of Clang?

We've had a little bit of a hurdle regarding importing graphics assets, but i think documentation can help solve that.

Method we use:
import .png for tilesets

What i'd like to do:
import .chr (as that's the native format for the NES and no scripted interpretation with risk of silent failure or human error is involved)

or, in lieu of that;
import .bmp (as that's the export format of NESST)
-this would at least save one step in the process running the bmp through a powershell script or photoshop.

What can actually be done in NESICIDE, currently?

_________________
http://www.frankengraphics.com - personal NES blog

Sorry it took me so long to get to this.
I just tried it. All you have to do is add the CHR file as a Binary File (Add Existing->Binary File... in the project browser context menu)
Then once you've done that you can add it to the graphics bank.