Staredit Network

I've already shared the details with a couple of other people (DoA and Q, possibly one other person) and there is one other person who has requested the details. I think I may just start a topic about it. BTW, I'll send that grp converter code to you later.


Well, it would also be useful for launching it from other modding tools if it would at least be able to open files from the parameters used when launching the program.

Plus you can use it from open-with if you dont want to associate it.

Off topic:
BK: is Kod code in polish? because all your stuff is in C:\Jakobs\Kod

Alot of people associate grps with retrogrp, so if you didnt allow it to open them using openwith or association. Honestly Ide continue using retro unless it had some godly like abilities

hi there it's realy long time no see uguys here
(i guess , i hadn't visit often here about 1month )
i had been practice SC play for SC semi-pro league in korea
So i really practiced hard Sc playing 1on1 with World Gosu player of SC

Anyways i saw this thread just at the right time
First of all, i'm very glad i see about Another new GRP editor
Anyhow i believe The more, the better.

After i had look around this thread and some of Screenshots
i feel it's seem to more better and more convenienced than SF's GRP ware

but i have a few of questions and oppionons for improvement of items

here i go listen and hopely refer to these
Question 1 : According to first BK's Screen, i though the arrow buttons are play buttons which makes play by self for frames and frameset of 17

but after look other posts, i think those buttons are just makes turn frames one by one by clicking
is that right? or am i took different ?

Anyways, if is that just turn frame one by one by clicking
how about give play buttons and auto playing funtions for it?

Question 2 : is it support diversity of pal files ? which for different file formats of pal file ?
many graphic artists use different software for their graphics
and some graphic editor use different pal formats

universally there are used 2 pal formats /
microsoft pal file and JASC pal file formats

so if it would support pal format diversity, many users would don't need work for change their pal format for it

Question 3 : would have plan to support import image one by one from option in frame list irrespective of file name numbering ?

here goes my some of oppinions for improvement of it

1: i think if could control play frames by slide bar and play/pause/stop buttons
that would be more friendly for users like the media players such as WMP / QT Player

and if it would be support funtions play with Scripts then it would really more useful
when modders write iscript for play frames codes
So they could use this funtions for test each scripts playing frames
just like this


As for Script type, if read codes from diveded source of one ID it would be no problem of laggy

So if u could make this funtion n if support selecting all of Action Animations by
dropdown list that could be more easier for explore each headers of unit's code

just like this


if u could make this funtions by ur hand
then this idea would be worth look upon

but i know if u would not have plan for iscripts or play animation funtion
this idea would be different from ur basic design

but if sharing progress with SF , it would worth look upon for she's project

I've been considering writing some palette reading and writing functions for BK. If I do, they will at least support the WC2 palette files (.ppl), SC palettes (.wpe), RIFF (microsoft) palettes, JASC palettes, and even reading palettes from and writing them to .bmp files.

As for the parts of your third question that are related to previewing the GRP based on its iscript, even if BK does not implement that (which I'm guessing it won't be implemented), it will at least be a part of the IceCC IDE I'm making. Though my program is not being coded in C++, it may still be possible to somehow interface it with GRPEdit. Heh, maybe BK could have it support letting other programs change which frame is shown in the preview through some kind of custom window message. If he doesn't know how, I could possibly help him with the details of it.

You're correct, I do not plan to implement IScript-dependent frame playback, just a simple one. As for interfacing between programs...hmm...I can imagine this being done, and I like the idea but I wonder why use GRPEd for it, if you plan to have the Gfx preview in your IDE?

Shiz...I begin to realize tha it would be much better if the GRP functionality would be directly coupled the Iscript one, yet if you're not using C++ for the IceCC IDE, it would be hard to put our workout together. What are you using btw:VB? Perl?

EDIT:And as for the palettes, unless they're some completely weird format, I can do it

looks good, retrogrp was becoming a pain in the arse

. ooooh a extract 1 button, good on you!

I'm using C#, which is why I suggested possibly doing it the way that I mentioned.


They aren't really that hard to figure out; it only took me a moment looking at them to figure them out.

I can imagine performing the interfacing through a DLL, but I am not really sure if less of a problem would be just transfering the C++ code to C#. GRPEd is not an advanced piece of a program, it's just a smart-ass use of GRPAPI, nothing more , so I think that at some point -preferable when you're done with the IceCC IDE- you could take a look at its code and see how much of a hassle would it take to transmogrify the code over to C#. TO my mind, the only difficult part would be the VCL-specific part, but this would gain completely new meaning in the GRP-related UI that you could put in.

If you make a COM component that exposes what you want other programs to play with in GRPEd (like MpqControl), .Net can interface with it by itself. Another way is to use managed C++ to make some sort of interface that C# can access. The last way I can conceive is a dll with exported functions. That's only if you want the IceCC IDE to modify your program state directly.

The method I mentioned wouldn't require any of the code from either program to be directly accessible by each other. With a handler for a custom window message, GRPEdit could allow any program to tell GRPEdit to switch to another frame. It could also have one to let the other program know how many frames there are. For example, Winamp uses this technique to allow other programs to get information from it and control Winamp.

This sounds good and simple enough, I like it. Now I only need to learn how to do this

Update over the progress with this program: I had to work out several memory-use and efficiency-related problems,hence a period of silence about GRPEd. Fortunately,I've succeded and completed the BMP-exporting functionality I've changed the design a bit and extracting frames is done using 2 modes: "All" and "Selected",which are self-explanatory I think. Also, I decided to abandon menus for the sake of interface-located buttons, for increased usability.

So, works do continue

any betas any time soon???

Well...I would love to say 'yes' but I can't really determine when I will have the basic features completed. I am working on some extra 'punch' power along with the Compile/Extract, to make the program at least somewhat useful, which means I need more time to make it all work together. Right now I am picking up the hardest piece of the cookie, so I will tell you how things look when I see how far can I progress with it. But I am sure you learned to be patient with FireGraft already...

actually, I have a very dirty iscript preview window in scmdraft2 somewhere, if you want I can clean it up some and put it on the debug menu

Cool Mind providing the source, if it's in C/C++?

IscriptChild = new CSC_IScriptChild(MainGUI->Engine->GameData, MainGUI->Engine->SoundEngine);
IscriptMaster->SetActiveChild(IscriptChild);
IscriptMaster->Run();
IscriptMaster->SetActiveChild(NULL);
delete IscriptChild;


;-)


like I said, its mangled into scmdraft debug code somewhere from back when I was working on my iscript code, I'll try to give it a neat window and put it on the debug menu...

ADDITION:
alright, this is just a dirty hack, but at least the things arent hardcoded anymore.

Great SI~! that's wat i've been give an oppinion for new iscript/GRP editors

my thing isn't an editor, it just tries to play iscripts according to what I know about the opcodes.

yes i said that features which is player w/ iscript opcodes.
i mean wasnt focus to editing

###Program development update###

For those who are interested, I've succesfully got GRP-BMP conversion working both ways. Thus, I consider the worst part as being dealt with, and it was easier than I thought. I will probably run some closed early-beta testing soon, to test the basic functionalities, so if anyone is interested then PM me or post here.

Hmm, I'd like to test out some of my "special" grps that I used as tests for my own code.

BTW, does your program have an option somewhere to save uncompressed GRPs? I don't really remember whether I put something into GRPAPI for a program using it to determine whether an existing one is compressed or not, though -- I don't think I did, but maybe I should put that in there.

SF>The DrawGrp function has such an option, as a bool parameter. No option for verifying though. As for your 'special' GRPs...please don't scare me, I'm happy that I finally got it to work in the first place, so don't hurt my feelings I bet it won't handle them properly, but heck - that's what testing period is for.

I'll progress with it a bit to stabilize it before I give it to 'the chosen ones'. I think you can expect the late-alpha (or rather early beta) sometime during this week.

I posted it in the Datedit thread as well, but I simply want to post it here as well - GRPEdit is delayed, probably quite seriously, because of my personal and real life reasons. I'll reopen and post up when/if things will shine up a bit. For now, that'll be it.
Cheers.
*TOPIC CLOSED*