[Kuddy]

[Risu2112]

M*$%&*#$^*@_#$BN(@#%NSAERNASFGAQW#RT3$^$M*%^*)^&*)%MERTNQWETQ@#$%B@^$WN%AERYTS{YPSE{RPTWE$TLNA:@#%LBQ@><{DLB<ANSDTF<OAW{C<RTPQ#<$XCPQ#>$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111

[KKairos]

Crap, that doesn't sound good, Ohki. What's up?

[Kuddy]

Oh, don't mind him. The new MZX has blown his mind.

[Risu2112]

To take full advantage of the port, and the fact that I will most likely never have to worry about robot memory again, SFmzx will be undergoing some radical changes. While I do plan to make all future code unbelivably sloopy, You can now expect the total file size to be FAR lower than innitialy expected. As a matter of fact, it's not unreasonable to say the 10megs worth of MZX' files (no music) will now be closer to one or two megs.

Sfmzx won't officialy be moving to 2.8+ for a little while to let exo catch up on all the reports, it has been tested in 2.8 with very promissing results though.

[apage43]

Backup, lots, or die.
Especially with the port in beta like it is.

[Micah]

Apage is right, he said what I was thinking.

[Risu2112]

Yeah yeah backups backups.

Hey any way thanks to apage I got the new animation for the planet, Now with a back! check it out.

OLD PLANET:


NEW PLANET:


While I might make a minor tweak to the perspective, that is probably what the final planet will look like.

Again, thats all code, not just a fancy picture, expect to see ~150 planets spinning around on release.

[apage43]

Comparison:
OLD ANIM:

NEW ANIM:


Yummy.

This post has been edited by apage43: 13 August 2004 - 01:39 AM

[asgromo]

VERY pretty... I can only wonder with my lacking MZX knowledge as to how you're doing that effect so flawlessly...

[Lachesis]

It looks amazingly real. KenOhki gets the Kuroneko's Award for Most Determined, Hard Working, Persistant MZX Game Designer =)

Attached image(s)

• 

This post has been edited by Kuroneko: 13 August 2004 - 05:13 AM

[RoSS]

asgromo, on Aug 12 2004, 11:33 PM, said:

VERY pretty... I can only wonder with my lacking MZX knowledge as to how you're doing that effect so flawlessly...

Copy block animations, I would assume.

[Micah]

Copy clock animations would be the 2nd worst method for animating that
way. The first would be placing each individual block for every frame. I would
think he would step up into using something more advanced.

[Xombie]

seeing as he has a lot of half color blocks that look to me like they change, I'm sure its a lot more complex than simply copying the surface. hell, he probably doesn't even draw the surface with the half color ones. looks to me like he draws it at double height and then uses some robotic magic to make the half color characters.

[Risu2112]

RoSS, on Aug 13 2004, 11:17 AM, said:

asgromo, on Aug 12 2004, 11:33 PM, said:

VERY pretty... I can only wonder with my lacking MZX knowledge as to how you're doing that effect so flawlessly...

Copy block animations, I would assume.

copy block animations? 25 frames for 150 planets? You are kidding right? That's robotic magic right there, All I have to do is supply a 54x23 map and the animation is generated on the fly. don't believe? send me a map and I'll spinify it.

[Dr Lancer-X]

RoSS: I don't see why he would use copy block anims since rendering the globe on the fly would be far easier to do than spending time drawing all the frames by hand, although now that I think about it having it rendered on the board then displayed is probably what you meant anyway.

~ Lancer-X

[GetDizzy]

Soooo... I hate to revive a topic, but how's starflight MZX doing?

[Superfunk]

How long do you think it would take to beat that game from the start?

[Revvy]

More like how long would it take to finish that game =(

[Koji]

Damn I just saw thoes globe thingies... That there is some high tech robotictry.

Did you use sin and cos to make a grid system that would deform the image into a psuedo globe? Or did you use some other tactic I wouldn't immediately think of. Also how did you get it to render so quickly? Whenever I try to real time render ANYTHING (Plasma project a long time ago, I was also working on a mandlebrot before I coppied it onto a disk and set it aflame) it ends up being god awfully slow...

[Dr Lancer-X]

Mandelbrot and julia sets are very difficult to do quickly in MZX, because they basically need you to be able to calculate lots of floating point arithmetic quickly. Since MZX doesn't as of yet support floating point, you need to manually calculate it, and it isn't a speedy task.

Possibly one could be made in a decent amount of time using the 640x350 charset as the drawing board if you used a small amount of iterations to determine if the number is in the set or not. Dunno though

[Koji]

Mine used blocks loke the other effects I was doing at the time ^^;;

Mine worked... but yeah it was HORRIBLY SLOW No one, but me, would sit there long enough to witness the wonderfulment. That and using integers severely limited the ammount of zoom. Perhaps with the port's long counter I can help in making more precision... I donno.

If I try it again sometime...

Also, as I understand it the mandlebrot has to be determined within a square... a rectangle would screw things up or change it entirely wouldn't it?

EDIT: Actually defining a rectangle would probably just squish it.

This post has been edited by Koji: 10 October 2004 - 03:34 AM

[Dr Lancer-X]

... eh? Determined in a square? Where did you get that?

Nothing forces you to clip to a square boundary. I use rectangles.

[Koji]

Lancer-X, on Oct 10 2004, 05:13 AM, said:

... eh? Determined in a square? Where did you get that?

Nothing forces you to clip to a square boundary. I use rectangles.

I thought that the mathematical definition of it had to be within a square.. you can display it however, but the mathematical boundary had to be a square... as I understand it...

[Dr Lancer-X]

These doesn't have to be any boundary though. Generally, you only get good fractals within -1.5 to 1.5, but the size can be anything you like.

[Risu2112]

Insidious, on Oct 8 2004, 05:27 AM, said:

Soooo... I hate to revive a topic, but how's starflight MZX doing?

SFmzx is at this point still having some difficulties with MZX2.8+ which make the game unplayable. Progress is slow on correcting the problem. In addition the game is undergoing a very thorough standardization of it's robots, which as it turns out is a very large task, and will probably involve some change in format of the systems and planets boards. Changes will likely reduce the total estimated size of the game to less than 1/4th of what it would be.

Said issues completion time is measured in weeks.

Average time spent on the project over the last two months has been roughly 6 hours/week, so despite the lack of updates the project is not idle. =\

Koji: Thanks, glad you like it. Expect to get very sick of staring at it for endless hours when you finnaly play the game =p

[Koji]

If you don't mind my asking, I'd like to see the engine in action if that's not to much trouble? ^^

You could post an MZB or just email it to Kojitakeo@gmail.com

[Revvy]

Quote

Changes will likely reduce the total estimated size of the game to less than 1/4th of what it would be.

WHY WHY WHY

[Risu2112]

Revvy, on Oct 10 2004, 05:20 AM, said:

Quote

Changes will likely reduce the total estimated size of the game to less than 1/4th of what it would be.

WHY WHY WHY

No, I mean file size will be ~1/4 of what it was going to be, the content will still be the same.

And Koji: it's not as tricky as it looks, the planet is rendered from a large rectangle image at the bottom of the screen, all it does is look at colors and duplicate them into sectors that are drawn at the top (which were defined manualy by hand -.-)

The whole thing is split into about 25 robots, thats why it's able to draw the whole frame in 1 cycle. It's just a lot of leg work, nothing too tricky or advanced and of course due to the limitations of text mode, the perspective is not by any means perfect. =\

[Dr Lancer-X]

Ken you do realise that with the "commands" counter 25 robots is probably going to be the same speed, or slower than 1 robot, don't you? Army-of-robot programming is mainly obsolete now