Hello ! I am a video game student @ILOI & I am very thankful, your speech is very motivating .
Except the dude clearly doesn't know much of anything about the 3D game pipeline. Yeah, if you're very skilled, a high poly sculpt could, certainly. But then there's retopology, UV mapping, texture baking, rigging, animating, other means of optimization once imported into the engine. Granted it wouldn't take anywhere near the production time of a AAA character (Which the High-poly sculpt took maybe 10-15 hours altogether, but the finished character took ~94 hours). And granted pokemon models aren't nearly as complex as that, but I think at least a 1-3 hours from start to finish to be a fair average expectancy of artists who know the work flow well enough. I just hate how people are so critical of artists when they clearly don't understand what goes into it.
SciTE is a SCIntilla based Text Editor. Originally built to demonstrate Scintilla, it has grown to be a generally useful editor with facilities for building and running programs. It is best used for jobs with simple configurations – I use it for building test and demonstration programs as well as SciTE and Scintilla, themselves.
Development of Scintilla started as an effort to improve the text editor in PythonWin. After being frustrated by problems in the Richedit control used by PythonWin, it looked like the best way forward was to write a new edit control. The biggest problem with Richedit and other similar controls is that they treat styling changes as important persistent changes to the document so they are saved into the undo stack and set the document’s dirty flag. For source code, styling should not be persisted as it can be mechanically recreated.
Scintilla and SciTE are currently available for Intel Win32, OS X, and Linux compatible operating systems with GTK+. They have been run on Windows XP, Windows 7, OS X 10.6+, and on Ubuntu 10.10 with GTK+ 2.20
The Windows version of Scintilla is a Windows Control. As such, its primary programming interface is through Windows messages. Early versions of Scintilla emulated much of the API defined by the standard Windows Edit and RichEdit controls but those APIs are now deprecated in favour of Scintilla’s own, more consistent API. In addition to messages performing the actions of a normal Edit control, Scintilla allows control of syntax styling, folding, markers, autocompletion and call tips. The GTK+ version also uses messages in a similar way to the Windows version.
This is different to normal GTK+ practice but made it easier to implement rapidly. Scintilla also builds with Cocoa on OS X and with Qt, and follows the conventions of those platforms. Scintilla does not properly support right-to-left languages like Arabic and Hebrew. While text in these languages may appear correct, it is not possible to interact with this text as is normal with other editing components. This documentation describes the individual messages and notifications used by Scintilla. It does not describe how to link them together to form a useful editor. For now, the best way to work out how to develop using Scintilla is to see how SciTE uses it. SciTE exercises most of Scintilla’s facilities.
In the descriptions that follow, the messages are described as function calls with zero, one or two arguments. These two arguments are the standard
lParam familiar to Windows programmers. These parameters are integers that are large enough to hold pointers, and the return value is also an integer large enough to contain a pointer. Although the commands only use the arguments described, because all messages have two arguments whether Scintilla uses them or not, it is strongly recommended that any unused arguments are set to 0. This allows future enhancement of messages without the risk of breaking existing code. Common argument types are:
|bool||Arguments expect the values 0 for
|int||Arguments are 32-bit signed integers.|
|const char *||Arguments point at text that is being passed to Scintilla but not modified. The text may be zero terminated or another argument may specify the character count, the description will make this clear.|
|char *||Arguments point at text buffers that Scintilla will fill with text. In some cases, another argument will tell Scintilla the buffer size. In others, you must make sure that the buffer is big enough to hold the requested text. If a NULL pointer (0) is passed then, for SCI_* calls, the length that should be allocated, not including any terminating NUL, is returned. Some calls (marked “NUL-terminated”) add a NUL character to the result but other calls do not: to generically handle both types, allocate one more byte than indicated and set it to NUL.|
|colour||Colours are set using the RGB format (Red, Green, Blue). The intensity of each colour is set in the range 0 to 255. If you have three such intensities, they are combined as: red | (green << 8) | (blue << 16). If you set all intensities to 255, the colour is white. If you set all intensities to 0, the colour is black. When you set a colour, you are making a request. What you will get depends on the capabilities of the system and the current screen mode.|
|alpha||Translucency is set using an alpha value. Alpha ranges from 0 (SC_ALPHA_TRANSPARENT) which is completely transparent to 255 (SC_ALPHA_OPAQUE) which is opaque. The value 256 (SC_ALPHA_NOALPHA) is opaque and uses code that is not alpha-aware and may be faster. Not all platforms support translucency and only some Scintilla features implement translucency. The default alpha value for most features is SC_ALPHA_NOALPHA.|
|<unused>||This is an unused argument. Setting it to 0 will ensure compatibility with future enhancements.|