Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Omegaclawe

Pages: [1]
1
General / Re: Getting user input and displaying formatted text.
« on: September 14, 2012, 10:30:57 pm »
Quote
- When looking for input, check which keys the user has pressed.
- Pass ASCII value of pressed keys to input class
No, watch the TextEntered event, not keys!

My implementation does, actually... mostly. It does watch the pressed keys for Up/down/left/right/delete, though. Backspace and return pass their own just fine, I think, but otherwise, the textentered event doesn't catch those keys... been a while since I looked at my implementation, though. :P

2
General / Re: Getting user input and displaying formatted text.
« on: September 14, 2012, 04:20:42 am »
For a project I've been working on, I've more or less made a console emulator... y'don't want its code... I'm not very good at "simple" and terrible at comments, but I can leave you with the idea behind the relevant parts:

- When looking for input, check which keys the user has pressed.
- Pass ASCII value of pressed keys to input class, translating arrows/delete/enter into special characters (some may be done for you)
- Check received text for specific special characters. If it isn't one of these, drop it at the appropriate position in a string, and increment the location
- If it is a key to move through the string, change your location variable accordingly. If it is delete/enter, submit the string or delete at the location.
- Draw the string to the screen.
- Use the built in functions of sf::Text and the location to find where to put the cursor. This will give you a proper X/Y value, though scaling can get... complicated. Draw a box here.
-- Alternate Method: Insert a Vertical Bar (|) into the string at the cursor location before drawing. Simpler, but messes with Kearning.

Might be more... elegant methods, but that should be enough for you to get coding one on your own, which, in the long run, will help you far more than dumping a bunch of code on you.

3
General discussions / Re: Origins: Coordinates vs. fractions
« on: September 09, 2012, 07:13:25 am »
Making this the standard would be... bad. It would still require the calculations, so in any situation where such an approach would not be useful, you've added time complexity. On top of that, using floating points that are merely between 0 and 1 would result in an overall decrease in accuracy and memory efficiency, as numbers greater than 1 and less than 0 would be, in most cases, useless. Potentially, you could use an integer as a percentage to get the full 4.3 billion possibilities as accuracy, but... more calculations would be required.

Does this really amount to much? Probably not. Linear additions to complexity are typically considered ignorable when non-linear complexity is in use. Still shaves off a bit of performance, though... and makes for somewhat uglier code.

Best to Keep it Simple, in the library. There's nothing stopping you from implementing a class or recoding the library to do it your way, but I doubt it'd provide you with anything more than a way to be lazier with easy code... and perhaps slightly more intuitiveness, but that's not necessarily a good thing.

In fact... actually, I challenge you to implement this. It'd be a great way to learn why the thing is the way it is.

4
Yeah... recompiling worked. Perhaps a big "for GCC versions <= 4.6" next to the download link would help, too. :P

Anyway... problem solved.

5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.0/configure --enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.0 (GCC)

I guess I'll try recompiling SFML when I get back tonight... not really that hard, but... it's a step I would have preferred to avoid.

6
While I was mixing them, fixing that does not seem to help much... does give me a bit more info on the stack trace, though... thought I'd post the relevant bits here:

Code: [Select]
#0 00000000 0x005454ea in std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::_Alloc_hider::_Alloc_hider(this=0x411598 <__tcf_6() (d:/programmes/mingw-4.5-dw2/bin/../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.h:261)
#1 00000000 0x00546595 in std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::basic_string(this=0x411598 <__tcf_6() (d:/programmes/mingw-4.5-dw2/bin/../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.h:425)
#2 00000000 0x004df325 in sf::String::String(this=0x411598 <__tcf_6() (D:\developpement\sfml-master\src\SFML\System\String.cpp:41)

7
After a few months of not coding due to... other obligations, I decided to pick up an old project on a new computer... took me a while to figure out that Code::blocks was using it's own Mingw instead of the one I installed, but I got it switched eventually, only to discover, according to this thread, that I had the wrong version. Switched to DW2, and it compiled fine... but...

Now, whenever I try to run the default constructor for sf::String, I get a segfault. Redid a fresh install of SFML, manually deleted all build artifacts, and rebuilt from scratch... still the same problem. Also restarted Code::blocks as I did so, for good measure. No luck. Any idea what I might have missed? :-\

8
Graphics / Solved: Crash on other systems than the build system.
« on: March 16, 2012, 11:16:24 pm »
Update: it's taken a long time, but after individually commenting out lines of code, transferring the result to other computers, And running it there and seeing if it still crashed, I have discovered that this had nothing to do with SFML, so much as trying to get a proper timestamp. Still investigating a fix.

Either way, I think this topic is done with here. Sorry about the original quality; wrote it in a rush on my way to work.

Update 2: Solved. Had to do with allocating to the heap where the stack was more appropriate. Should have paid more attention to those boost tutorials I was c/ping then editing.

Pages: [1]