Since the div2 port is now nearly finished, it's time to start adding new features. In addition to high colour, what should we have in the new IDE and engine?
Post your comments here and i will add them to the lost and evaluate them for inclusion :)
The ability to render an scroll on a map is very useful. Mostly for zoom effects :)
Also, to should definitely take a look at the features added by fenix and BennuGD through the years, like the alpha local variable, for example.
They become so familiar to the community, that I couldn't imagine not having them in DIV
Just don't open the box of thunders, or you're goint to be overflowed with suggestions :D
But I always missed a good sound library... ok, maybe mod sound library may I say, because today I cannot make games with speed selector, manual loops, runtime activation/deactivation of channels... the cool mod stuff :D
But also I cannot compose music, so... :P
DIV has always supported MOD files - and soon will support VGM music
also, the local alpha (transparent) var is in progress for the 32bits version :)
Yes, it had support for MOD, S3M and XM, but not IT, and can't change play speed, mute channels or pitch shifting, just PLAY_SONG, STOP_SONG, RESUME_SONG and... that's it. I don't remember more functions associated to mod files.
I remember you can pitch shift sound effects, like in Speed for Dummies, but not with music ;)
1. DIVDX trial version to download (or limited free version as "construct 2", unity free)
example: (only window exe export to free version)
2. SDK download to develop modules or improve tools
thx.. nice tool ...
Something that would be very useful can be some kind of GUI framework, I remember that Splinter was making a very nice one, but he lost the sources when his hard-disk goes kaput and he doesn't want to redo all the work. I know that this can be very difficult and tedious to code, but I believe it can be a very nice addition to Div3.
Hi!
I finally had the chance to read all the information that had been posted on DIV DX and the impressive amount of platforms it is targetting! Nice piece of work!
Somewhere I read that the native DIV graphic-related formats (MAP, FPG, ...) had been refreshed to support 32bpp. I wonder if (and wish that) the specification of the format will be available (as it was for the original DIV) for us to be able to make tools to support them outside DIV Gui, or if there is no intention of sharing that kind of information.
Regards,
Darío
Quote from: darío on February 21, 2016, 12:55:26 PM
Somewhere I read that the native DIV graphic-related formats (MAP, FPG, ...) had been refreshed to support 32bpp. I wonder if (and wish that) the specification of the format will be available (as it was for the original DIV) for us to be able to make tools to support them outside DIV Gui, or if there is no intention of sharing that kind of information.
Yes the file formats will all be published when they are finalised :)
Excellent!
Thats great news, i hope you opt format specification easy to distinguish from other already existing 16 and 32bpp formas of bennu... I will gladly add support for them in my applications egen they become available.
It's really necessary to create new FPG16 and FPG32 file formats? They're pretty the same as FPG8, with the basic improvements, aren't they?
Quote from: Drumpi on February 23, 2016, 09:03:55 PM
It's really necessary to create new FPG16 and FPG32 file formats? They're pretty the same as FPG8, with the basic improvements, aren't they?
The problem is that fpg are not compressed. 16 and 32 bit fpgs would be huge if we kept the map format
Fenix/Bennu/PixTudio already supported 16 and 32bpp maps, fpgs and fnts. I guess what Drumpi is asking is if it is not possible to use Bennu's Map and Fpg formats for the 16 and 32bpp versions. That would bbe of course very interesting, because there is already a limited amount of tools that can operate these formats, but you might have other plans... In that case I hope you opt for different magic numers than bennu uses today (bennu uses "m16", "m32", "f16", "f32") so as not to complicate the live for the already existing tools.
Bennu/PixTudio formats support transparently GZip compression.
Quote from: darío on February 23, 2016, 11:49:42 PM
Fenix/Bennu/PixTudio already supported 16 and 32bpp maps, fpgs and fnts. I guess what Drumpi is asking is if it is not possible to use Bennu's Map and Fpg formats for the 16 and 32bpp versions. That would bbe of course very interesting, because there is already a limited amount of tools that can operate these formats, but you might have other plans... In that case I hope you opt for different magic numers than bennu uses today (bennu uses "m16", "m32", "f16", "f32") so as not to complicate the live for the already existing tools.
Bennu/PixTudio formats support transparently GZip compression.
Well, this is an interesting point
I don't think it is in Div's interest to adopt 3rd party formats, even if they are from forks of a copy system. The DIV FPG Header uses fpg\x1a\x0d\x0a - and i'm going to guess (since i dont know) that m16 / m32 / f16 / f32 are used in place of the original "fpg" first 3 bytes
Also I am not sure it is is wise to adopt a file format "owned" by bennu for the div main branch
Maybe I will support the bennu formats and also have a more "official" fpg format :)
It's not "Bennu's format". It's, in fact, Fénix format, and it's supported by Fénix/BennuGD/PixTudio/DivGO and all of its tools.
The only "div-like" not supporting it is Gemix.
In my opinion, the best for the community would be that official DIV supported the "de-facto" standard created in Fénix.
It would help the community to use different div-likes easier.
Anyway, those formats can't be copyrighted or patented.
Quote from: PiXeL on February 24, 2016, 11:50:31 AM
It's not "Bennu's format". It's, in fact, Fénix format, and it's supported by Fénix/BennuGD/PixTudio/DivGO and all of its tools.
The only "div-like" not supporting it is Gemix.
In my opinion, the best for the community would be that official DIV supported the "de-facto" standard created in Fénix.
It would help the community to use different div-likes easier.
Anyway, those formats can't be copyrighted or patented.
Ok well i will consider them
However saying that only gemix doesn't suppory those formats is a little bit bad, since fenix,bennu and pixtuduo all share a codebase so the format is inherited. (Asside from divgo of course)
The move to 32bits is a big step, and it's important we have this discussion. I need to look into the fenix 32/16 formats and see how well they fit. It would be silly of me to reject the formats without looking into them but also silly for me to adopt them as "official" without investigation :)
I don't remember right now.
It's possible to compile a .prg in command line ?
Example: @d.exe mygame.prg
Quote from: MikeDX on February 24, 2016, 04:05:17 PM
The move to 32bits is a big step, and it's important we have this discussion. I need to look into the fenix 32/16 formats and see how well they fit. It would be silly of me to reject the formats without looking into them but also silly for me to adopt them as "official" without investigation :)
Agree!
These projects are all open source, and I really think they can help DIV catch up with the latest features faster. But it's importante to do a good implementation.
Yes, it's a good point. There are a few differences between DIV FPG and Fenix Fxx formats. They are minor, but what you say, you can force to put as official if:
- They are free but not DIVX.
- They aren't 100% compatible (I didn't know about Gemix).
- There are tools for file conversion.
And yes, they are huge, but when they are loaded, they are unpacked, always. Even when they are gzip compressed, PNG format, or anything else. I don't know the impact of using memory compressed maps.
Quote from: FreeYourMind on February 24, 2016, 04:10:36 PM
I don't remember right now.
It's possible to compile a .prg in command line ?
Example: @d.exe mygame.prg
no not yet, this is a future feature although the ide can currently handle it. Since there is no div32run.dll equivalent at the moment, compiling the prg is a little unhelpful :)
If the specification is open I do not see a big deal in having a new format, but at the same time I believe that bringing a new format without any added value compared to the existing ones might not be the best. If, on the other hand, the new formats respond to some real need, then I can only wish that they will be open enough so as we can support them outside DIV gui, and that they are easily distinguished in their headers as compared to the formats used by other div-likes.
he used format would be great * .ogg or * .mp3 music
* .prg also cut files in multiple using similar BennuGD include for easier debug
and put flag to debugger in code
Quote from: Fuynfactory on March 01, 2016, 11:07:41 AM
he used format would be great * .ogg or * .mp3 music
* .prg also cut files in multiple using similar BennuGD include for easier debug
and put flag to debugger in code
OGG and MP3 support is on the road map, as is PRG includes :)
Unicode and TTF support is pretty useful for targeting many other language users if possible.
But this may break some existing string operation.