Super Mario Bros. X Forums

SnifitGuy wrote:

GhostHawk wrote:

Lord Nagaviper wrote:Lol such April Fools

On the topic of VSMBX, this project is looking really good and I can't wait to see what you can do with it in the future. Keep up the good work man!

Thanks! I'm going to try releasing beta 1.0.1.4 on either April 12th or by May 20th at the latest.

Omg, you scared me about this being cancelled. Also, is it 1.3.0.1 or 1.0.1.3? You have 1.3.0.1 on the OP.

Sorry, must have been a typo. It's 1.0.1.3 for the current public beta.

Pilzinsel64 wrote:Oh!
Sorry for the PM what I sent you.

I like VSMBX and i'm happy about the new functions by Blocks and Tiles:
- Undo
- Redo
- Save-Mode

But one thing:
the sizable blocks doesn't realy working.

So, thanks for the willingness smbx to reprogram and then to add new functions.

Happy Easter! :>

I guess I've forgot about fixing some of the sizable blocks bugs, thanks for reminding me. Also, Happy Easter back at ya.

GhostHawk, how will the custom gfx work? Same way as smbx? (custom gfx folder's name=level's name)

SMBX-fan wrote:GhostHawk, how will the custom gfx work? Same way as smbx? (custom gfx folder's name=level's name)

Most likely, yes.

EDIT:

1.0.1.4 Update Spoilers below:

GhostHawk wrote:

SMBX-fan wrote:GhostHawk, how will the custom gfx work? Same way as smbx? (custom gfx folder's name=level's name)

Most likely, yes.

EDIT:

1.0.1.4 Update Spoilers below:

Spoiler: show

Colored blocks!



Working on performance when using a lot onscreen. This should save resources that would be taken up by custom graphics! Also, the brightness of the level background can be changed. I don't think actual "glowing" blocks will be implemented in this version, so for now the "Glow" meter will just alter the Alpha (transparency) of the tile.

A lot of bug fixes are coming, with a more stable gameplay engine as well.

Heh, good idea of usage OpenGL render color over textures
For example, the regular case:
when we will call glColor4f function with all 1.0f parameters will be rendered white polygon, but if texture was applied, it will be rendered in regular form.
glColor4f( 1.f, 1.f, 1.f, 1.f);
BUT, when we try to render colored polyhon:
glColor4f( 1.f, 0.907.f, 0.4.f, 1.f);
and when we will apply texture - it will be rendered with changed hue.
Therefore we can do anything with OpenGL!

Awesome work! But for this color thing I think we need more beta testers! This is what a 8th generation sandbox game should offer.
Is that possible to have something like in Paint.NET, which is like this:
The color 119EFF has:
R: 17
G: 158
B: 255
I hope i was understandable.

Wohlstand wrote:A lot of bug fixes are coming, with a more stable gameplay engine as well.[/spoiler]

Heh, good idea of usage OpenGL render color over textures
For example, the regular case:
when we will call glColor4f function with all 1.0f parameters will be rendered white polygon, but if texture was applied, it will be rendered in regular form.
glColor4f( 1.f, 1.f, 1.f, 1.f);
BUT, when we try to render colored polyhon:
glColor4f( 1.f, 0.907.f, 0.4.f, 1.f);
and when we will apply texture - it will be rendered with changed hue.
Therefore we can do anything with OpenGL! [/quote]

Actually this can and was done without OpenGL. I used a regular color matrix, and set image attributes to use that matrix which can be done with plain 'ol GDI+.

SMBX-fan wrote:Awesome work! But for this color thing I think we need more beta testers! This is what a 8th generation sandbox game should offer.
Is that possible to have something like in Paint.NET, which is like this:
The color 119EFF has:
R: 17
G: 158
B: 255
I hope i was understandable.

I'm not sure if I do quite understand entirely, but you do have control over the RGB variables in the exact same way you would in Paint.NET.

GhostHawk wrote:

Wohlstand wrote:A lot of bug fixes are coming, with a more stable gameplay engine as well.
Heh, good idea of usage OpenGL render color over textures
For example, the regular case:
when we will call glColor4f function with all 1.0f parameters will be rendered white polygon, but if texture was applied, it will be rendered in regular form.
glColor4f( 1.f, 1.f, 1.f, 1.f);
BUT, when we try to render colored polyhon:
glColor4f( 1.f, 0.907.f, 0.4.f, 1.f);
and when we will apply texture - it will be rendered with changed hue.
Therefore we can do anything with OpenGL!

Actually this can and was done without OpenGL. I used a regular color matrix, and set image attributes to use that matrix which can be done with plain 'ol GDI+.

SMBX-fan wrote:Awesome work! But for this color thing I think we need more beta testers! This is what a 8th generation sandbox game should offer.
Is that possible to have something like in Paint.NET, which is like this:
The color 119EFF has:
R: 17
G: 158
B: 255
I hope i was understandable.

I'm not sure if I do quite understand entirely, but you do have control over the RGB variables in the exact same way you would in Paint.NET.

by anyway you hates your CPU with software render
Shaders are provides ability do anything yourself but with GPU computing (even beautiful effects like glow too)

GhostHawk wrote: Most likely, yes.

EDIT:

1.0.1.4 Update Spoilers below:

Spoiler: show

Colored blocks!



Working on performance when using a lot onscreen. This should save resources that would be taken up by custom graphics! Also, the brightness of the level background can be changed. I don't think actual "glowing" blocks will be implemented in this version, so for now the "Glow" meter will just alter the Alpha (transparency) of the tile.

A lot of bug fixes are coming, with a more stable gameplay engine as well.

I love this idea! it's even cooler with the animation tool for custom sprites.

Once global event was suggested in 2014 by someone but I have some little ideas about this: there should be a selective global event function.
There is an event, which is called 'goomba death' and when it happens, the layer 'goomba block' dissappears. (in the grass level.vlvl for example)
There is a goomba with the event 'goomba death' on Death.
The 3 modes of the event:
Unglobal: the event only affects to the level where you made it
Selective global: the event affects to other levels too, but you have to pick the levels where you want the effect (write the level name, like desert level.vlvl)
Global: affects to all the levels in the episode's folder without any selection

And global events probably mean global layers too because having global layers next to the unglobal ones isn't good idea.

Other ideas from the past what are really important (not the most, but almost the most important ideas):
Time limit
Multiple checkpoints
World map events

Q: About when will the first enjoyable (not full) version release?
enjoyable=not as buggy as an usual beta (say the upcoming 1.0.1.4 as the usual beta) but it's buggier than the full version, so it's a playable version actually. In VSMBX i mean this as easy editing and good enough physics.

EDIT: still the copying of SMBX is more important than plenty of new features before it seems like i want to start bulding a house with the roof.

WoW!
Can I asked a little?
Can I change the level from VSMBX files to original SMBX?
And can I use LunaDll or LunaLua?

alti0204tri wrote:WoW!
Can I change the level from VSMBX files to original SMBX?

Nope, because VSMBX will have way more functions than SMBX. But you'll be able to convert SMBX files to VSMBX because.

alti0204tri wrote:And can I use LunaDll or LunaLua?

Again: no. But the source code is public so you can do stuff what you can in LunaDLL and LunaLua.
______

Idea: is a copy-paste thing possible in editor? It would be good for repeating moving layers. (like the horizontally moving lava in volcano levels)

And however I miss the 'right click=back to the selection' thing.

SMBX-fan wrote:

alti0204tri wrote:WoW!
Can I change the level from VSMBX files to original SMBX?

Nope, because VSMBX will have way more functions than SMBX. But you'll be able to convert SMBX files to VSMBX because.

Heh, same in the PGE with new LVLX format: but by anyway is possible to save file into LVL back, but with loss of new features like Z-indexes, additional item fields, position bookmarks (which will be saved into separated meta-file). By anyway currently the SMBX64 LVL file format has more features than VLVL except new things like Z-layer for BGO's or gamma regulators which a VLVL unique things. By anyway, VLVL currently is not supports multi-sections, therefore to convert LVL into VLVL the removing of all 2..21 sections is required. Also because impossible to put elements out of section, than items would be removed too.
Result: is much easier to convert from VLVL to LVL back with loss of Z-layers and gamma regulators. The conversion from LVL to VLVL is harder because we should:
1) remove all elements which located out if 1'st section
2) remove all settings of last 20'th sections
3) skip all waters/quicksands
4) skip all layers and events

Inside PGE are both files (new LVLX and old LVL) uses united internal data structure and application (editor or engine) has no problems with reading/writing of difference file formats. All format specific features are applying in the reading or writing function which directly parses or generates raw file data. By anyway you (GhostHawk) would to create structure with lists which will contain structures per each element before you will draw them in the level window. When some actions are did, sync them by special Array-ID values

SMBX-fan wrote:

alti0204tri wrote:And can I use LunaDll or LunaLua?

Again: no. But the source code is public so you can do stuff what you can in LunaDLL and LunaLua.

LunaDLL/LunaLUA is a specification which would be implemented too, but except memory functions which will be dummy. Autocode parser easily can be implemented and used with internal calls/events, etc. But this depends to Ghosthawk's purposes and skills if he will do works to implement than specifications.

SMBX64 in fact is a standard of I/O, internal metrics, external data formats and structures. This means, even internal application standards is not compatible with SMBX, you would have to read and write than original formats when you know internal system.
______

SMBX-fan wrote: Idea: is a copy-paste thing possible in editor? It would be good for repeating moving layers. (like the horizontally moving lava in volcano levels)

And however I miss the 'right click=back to the selection' thing.

To implement copy-paste GhostHawk should implement multi-selection rectangle and true drag&drop system. Context menu would be implemented too. It should provide an access to properties without taking out of the item. This is a safe unlike you grab out item or when you should remove bunch of placed items to replace them.

Wohlstand wrote:

SMBX-fan wrote:

alti0204tri wrote:WoW!
Can I change the level from VSMBX files to original SMBX?

Nope, because VSMBX will have way more functions than SMBX. But you'll be able to convert SMBX files to VSMBX because.

Heh, same in the PGE with new LVLX format: but by anyway is possible to save file into LVL back, but with loss of new features like Z-indexes, additional item fields, position bookmarks (which will be saved into separated meta-file). By anyway currently the SMBX64 LVL file format has more features than VLVL except new things like Z-layer for BGO's or gamma regulators which a VLVL unique things. By anyway, VLVL currently is not supports multi-sections, therefore to convert LVL into VLVL the removing of all 2..21 sections is required. Also because impossible to put elements out of section, than items would be removed too.
Result: is much easier to convert from VLVL to LVL back with loss of Z-layers and gamma regulators. The conversion from LVL to VLVL is harder because we should:
1) remove all elements which located out if 1'st section
2) remove all settings of last 20'th sections
3) skip all waters/quicksands
4) skip all layers and events

Thanks for the information. I wanted to talk about the future when the game is almost completed and almost has got 90% of the original SMBX's functions. And I know the converter don't release before everything gets fine for converting.

Wohlstand wrote:

SMBX-fan wrote:

alti0204tri wrote:And can I use LunaDll or LunaLua?

Again: no. But the source code is public so you can do stuff what you can in LunaDLL and LunaLua.

LunaDLL/LunaLUA is a specification which would be implemented too, but except memory functions which will be dummy. Autocode parser easily can be implemented and used with internal calls/events, etc. But this depends to Ghosthawk's purposes and skills if he will do works to implement than specifications.

SMBX64 in fact is a standard of I/O, internal metrics, external data formats and structures. This means, even internal application standards is not compatible with SMBX, you would have to read and write than original formats when you know internal system.

I don't think LunaDLL's VSMBX compatibility is important. I don't know much programming but what you can do with LunaDLL, you will be able to do by editing the source code. (and maybe using the new functions if there are)
Wohl: good luck for your PGE editor project and when level testing will be possible in that, I'm going to switch the regular smbx editor.

SMBX-fan wrote: Thanks for the information. I wanted to talk about the future when the game is almost completed and almost has got 90% of the original SMBX's functions. And I know the converter don't release before everything gets fine for converting.

By anyway I will port my PGE file formats library into .NET (In the C#, and when will try to convert into VB.NET) when GhostHawk would use them to read/write SMBX64 file formats. Now I have a full and absolute support of all SMBX file formats from SMBX 1.0 to SMBX 1.3 (1.3.0.1 is a same 1.3!).

Wohlstand wrote: I don't think LunaDLL's VSMBX compatibility is important. I don't know much programming but what you can do with LunaDLL, you will be able to do by editing the source code. (and maybe using the new functions if there are)
Wohl: good luck for your PGE editor project and when level testing will be possible in that, I'm going to switch the regular smbx editor.

Level testing is POSSIBLE in the current version of PGE Editor (0.3.0-beta) and I have multiple ways:
1) internal test with PGE Engine: (when you installed Engine part in the installer or downloaded and unpacked file from laboratory, you gets able to open "Test"->"Run testing" menu).
http://www.youtube.com/watch?v=d73vXuSZDJs
But don't forget about current version of PGE Engine 0.0.7-pre-alpha. Now it supports world maps and you would play episodes in them (make shortcut with "%UserProfile%\.PGE Project" path and open it. Here you can make "worlds" folder to put SMBX episodes, and then run pge_engine.exe to start game), but it still in development, but currently I near to have working implementation of SMBX64 standard to play SMBX levels with full support of everything include layers and events, NPC's, graphics of playable characters, etc.

2) testing via SMBX. This gimmick works when LunaLUA starts from 0.5.3 is installed in the SMBX.
When SMBX Editor is runned and minimized, you have menuitem "Test" -> "Run test via SMBX", when PGE Editor will be automatically minimized, and SMBX will be switched. Level will be automatically opened and testing will be ranned.
http://www.youtube.com/watch?v=fIyjAaNrhHw

Anyone can give me another link please?
Mega.co.nz is not run perfectly on my Browser, it's always be slow down.

The Mega link is invalid.

Ghosthawk, Anyway you should start to use the GitHub: you will have version control system which giving you ability keep source code in safe and also you have space to publish your releases (like here: https://github.com/Wohlhabend-Networks/ ... t/releases)

Kind of hit a road block with color and performance, so I'll just have to recommend not making levels that rely on color just yet. I just finished fixing some player animations (that I've noticed), and I will soon start working on making jump physics look smoother, and then work on stuff like momentum and velocity. Then *drum roll* AI. Don't hold me to it, but I will try and have 1.0.2 (not 1.0.1.4 anymore because of major changes) up by May 20th.

2 words. Pikmin sprites

Nice to see progress on this is still going. Ive been away for a while and unaware of this project's progress.