CrazyEddie's GUI System: Version 0.7.0 is Released!

Official announcements from the CEGUI project.

Moderator: CEGUI Team

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby CrazyEddie » Thu Sep 24, 2009 18:09

scriptkid wrote:What i don't understand is whether i should or shouln'd have picked the latest? ;)

I think it was the right thing to do; at least, I'd have done the same ;)

User avatar
scriptkid
Home away from home
Home away from home
Posts: 1178
Joined: Wed Jan 12, 2005 12:06
Location: The Hague, The Netherlands
Contact:

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby scriptkid » Fri Sep 25, 2009 14:42

Jamarr wrote:*edit: just wanted to add why I think /MT is better - because this option statically links the vc runtime libraries, where as /MD uses dynamic linking (requireing dlls); if you are going for a static-build, you most likely want the vc runtime linked statically as well.


This has just been committed to SVN, it was indeed something which we had overlooked. DebugStatic links as /MTd and ReleaseStatic as /MT now.

I am not sure how the dependencies were build. I guess that -in order to support complete static builds- all dependency projects should be linking statically as well, even though they might be DLLs themselves.
Check out my released snake game using Cegui!

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby Jamarr » Fri Sep 25, 2009 16:11

scriptkid wrote:
Jamarr wrote:*edit: just wanted to add why I think /MT is better - because this option statically links the vc runtime libraries, where as /MD uses dynamic linking (requireing dlls); if you are going for a static-build, you most likely want the vc runtime linked statically as well.


This has just been committed to SVN, it was indeed something which we had overlooked. DebugStatic links as /MTd and ReleaseStatic as /MT now.

I am not sure how the dependencies were build. I guess that -in order to support complete static builds- all dependency projects should be linking statically as well, even though they might be DLLs themselves.


Right. It's hard to remember the details now, but I am fairly certain that all of the statically-built dependencies are built with /MD instead of /MT. So to get a 100% statically built library I had to go find, download, and rebuild all of the dependencies with the /MT switch. I believe that if you try to link libs with /MD against a lib with /MT you will get some symbol-already-defined linker errors.
If somebody helps you by replying to your thread, upvote him/her as a thanks! Make sure to include your CEGUI.log and everything you tried when posting! And remember that we are not magicians!

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby CrazyEddie » Fri Sep 25, 2009 19:14

I think really we're going to need two sets of dependencies - one for the dynamic builds with /MD(d) and another set for the static builds with /MT(d). Otherwise we're never going to be able to please everybody - since I'm the 'dependencies guy' I'll look into this shortly - early next week - and see whether this can be done for a 0.7.1 release.

CE.

User avatar
Van
Just can't stay away
Just can't stay away
Posts: 225
Joined: Fri Jan 21, 2005 20:29
Contact:

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby Van » Sat Sep 26, 2009 13:42

Woot! I'm glad to see this! been waiting along time!
:pint: :pint: :pint:

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby CrazyEddie » Sat Sep 26, 2009 15:42

Hey! Currently the release is looking a bit shabby to be honest. While I knew there would be some issues with such large changes, the extent and range of the issues coming in are surprising :lol: With any luck the upcoming 0.7.1 might be a bit more solid...

Image

CE.

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby Jamarr » Mon Sep 28, 2009 23:18

CrazyEddie wrote:I think really we're going to need two sets of dependencies - one for the dynamic builds with /MD(d) and another set for the static builds with /MT(d). Otherwise we're never going to be able to please everybody - since I'm the 'dependencies guy' I'll look into this shortly - early next week - and see whether this can be done for a 0.7.1 release.

CE.


Right now you there are two pre-compiled download packages: 1) dynamic-cegui + static-cegui and 2) dynamic-deps + static-deps, right? Instead, why not offer: 1) dynamic-cegui + dynamic-deps (with/MD) and 2) static-cegui + static-deps (with /MT). This seems far more pratical.

Maybe my judgement is way off, but it seems like the number of users who want static and not /MT, as well as the number of users who download cegui and not the dependencies are few and far between. Judging solely by forum posts, I would guess that 99% of users fall into two categories: 1) those who want dynamic cegui+deps and really don't care about the vcruntime switch, and 2) those who want static cegui+deps with the /MT switch. You can't possibly cater to everyone, but I think this would cover the majority. /shrug

I could personally care less either way, as I've already gone through all the trouble. But I think having these two packages instead of the current would have made my life easier in the beginning :wink:
If somebody helps you by replying to your thread, upvote him/her as a thanks! Make sure to include your CEGUI.log and everything you tried when posting! And remember that we are not magicians!

User avatar
scriptkid
Home away from home
Home away from home
Posts: 1178
Joined: Wed Jan 12, 2005 12:06
Location: The Hague, The Netherlands
Contact:

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby scriptkid » Tue Sep 29, 2009 07:25

It sounds good from the point of having less files, but grouping those two packages as one would only work for the SDKs. Because people who want to build the sources themselves, only need the dependencies, right?
Check out my released snake game using Cegui!

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby CrazyEddie » Tue Sep 29, 2009 09:38

Yeah, currently we have:

Source package
Dependencies package built with /MD (one per compiler)
SDK - includes dependencies (one per compiler)

I thought we're looking at:
Source package
Dependencies package containing one version of everything built with /MD and one version built with /MT (one per compiler)
SDK - including dependencies (one per compiler).

However, we do then have the situation where we have people downloading twice as much as they need - in that circumstance we might consider a 'static deps package' and a 'static SDK' separate from the dynamic versions. Though I agree here that this creates a lot of new files, packages and confusion.

Personally, I'm all for any solution that reduces the amount of effort I have to put in :D So, if someone tells we what that is, that's what we'll do :)

CE.

tbaldree
Just popping in
Just popping in
Posts: 1
Joined: Sun Oct 04, 2009 07:41

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby tbaldree » Sun Oct 04, 2009 07:45

A quick question - I started migration to .7 for Torchlight ( REALLY wanted those embedded color changes in text, as will allow us to do a lot of UI polish that is otherwise too cumbersome to do ) - however I noted the removal of getFormattedTextExtents from font, and ended up having to back it out.

We were relying on this quite heavily to be able to determine the correct extents for our relatively complex item tooltips, which have lots of differences in internal formatting, with some areas needing wrapping and others not. At any rate, is there an alternative to this, whereby the width of a wrapping text element can be determined prior to setting the sizes on everything? Thanks!

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: CrazyEddie's GUI System: Version 0.7.0 is Released!

Postby CrazyEddie » Sun Oct 04, 2009 10:41

Hi there,

Awesome work on Torchlight :)

This is kind of covered here: viewtopic.php?f=10&t=4363. Though depending on exactly how you have the windows and text arranged - and on who and how things are being drawn - this may or may not be completely relevant.

A little bit of history and what have you, so that you'll be able to decide the best course of action... The removal of this (and other) functions is due to us removing the formatting responsibilities from Font and re-implementing it elsewhere, this is all related to the string markup changes (because a window text is no longer just text, so Font does not have enough information to return correct extents information). Basically what happens now is that the input text string is parsed into a CEGUI::RenderedString - which is largely the level at which text is rendered in the newer CEGUI (Editbox widgets being an exception). Formatting is now applied at the RenderedString level via a FormattedRenderedString, which basically wraps the RenderedString in order to do formatting.

So what's the importance of all that? If you've previously been drawing your own formatted text (say via Font::drawText and supplying a TextFormatting value) then this is no longer available and should be updated to use RenderedString and FormattedRenderedString - doing this will give you access to the FormattedRenderedString::getHorizontalExtent and FormattedRenderedString::getVerticalExtent functions that return the pixel extents of the string as currently formatted. If you're not currently drawing the text directly, but are using some combination of other window types, things become possibly more complex. As seen in the thread linked, I've added property updates to expose the formatted extents for the StaticText - so that may be enough for you. If you're using other window types instead (or as well), it may be that those will need to add functions and/or properties to expose the extents values from the internally used FormattedRenderedString objects (though I think it's only StaticText affected anyway - will check once I get my dev system up and running again :roll:).

HTH

CE.


Return to “Official Announcements, Works in Progress, and Future Directions”

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest